- changed status to open
- removed comment
Calculate solution error in EinsteinExact
I implemented a facility to calculate the solution error as analysis quantity in EinsteinExact. I pushed this to a new branch eschnett/solution-error.
Keyword:
Comments (6)
-
reporter -
- 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.
-
reporter - changed status to resolved
- removed comment
Applied.
-
- 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:
- 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
- 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.
-
- 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.
-
reporter - removed comment
The new variables would only be active if requested in the parameter file.
- Log in to comment