Calculate solution error in EinsteinExact

Create issue
Issue #1560 open
Erik Schnetter created an issue

I implemented a facility to calculate the solution error as analysis quantity in EinsteinExact. I pushed this to a new branch eschnett/solution-error.


Comments (6)

  1. Barry Wardell
    • changed status to open
    • removed comment

    This looks good to me. It would be nice to avoid using the internal TensorTools notation with the replacement rules, but I can't think of a good way to do so right now, so please feel free to merge the proposed version into master.

  2. Ian Hinder
    • removed comment

    The way I have done this in the past is to add new variables for the exact solution rather than using the ADM variables. You can then output these, which give you the exact solution, and add a calculation which subtracts the ADM variables from the exact solution, and populates the error variables. This way, you can have all quantities available, and as a side benefit, you don't need to do the pattern matching on the calculation.

    So you would have this:

    calcExact = {
      gxxExact -> ,
    calcADMBase = {
      gxx -> gxxExact,
    calcError = {
      gxxError -> gxx - gxxExact,

    You would then schedule this so that the exact, ADMBase and error calculations are always run at INITIAL. Then, depending on the parameters, you would either:

    1. Calculate exact, ADMBase and error also during evolution. This would preserve the current expected behaviour of the ADMBase variables containing the exact solution for the whole evolution. OR
    2. Calculate just the exact and error variables during evolution, so that the error variables contain the error of the (separate) evolution of the ADMBase variables.

    It is also useful to compute the gridfunction whose norm is the norm of the whole solution error. i.e.

      uErr = sqrt((gErr_ij)^2 + (KErr_ij)^2 + alpErr^2 + (betaErr^i)^2).

    Then you can output the norm of this from Cactus, and you can look at convergence for the entire (ADM) solution very easily.

  3. Barry Wardell
    • changed status to open
    • removed comment

    This does sound like a good solution. The only potential problem is that simulations could use a lot more memory since there are now a whole extra set of variables required for the exact solution. Would you consider that to be a problem? I guess we're typically not limited by memory in situations where exact solutions are used, so maybe it's not such a big deal.

  4. Erik Schnetter reporter
    • removed comment

    The new variables would only be active if requested in the parameter file.

  5. Log in to comment