add evolution method "stationary" to ADMBase

Create issue
Issue #1399 closed
Roland Haas created an issue

This method is similar to "static" in that it can be used for Cowling runs, it differs from "static" in that it schedules the initial data routine after any grid changes and does not apply boundary conditions or SYNC calls. It can thus be used if one can compute the required metric/shift/lapse easily in a pointwise manner and would like to have exact (non-prolongated) data in the buffer zones.

Keyword: ADMBase

Comments (6)

  1. Erik Schnetter
    • removed comment

    In this context, I do not understand why there should be a difference between "static" and "stationary", and why this difference should include re-applying initial conditions when the grid structure changes... If we do this, it should probably have a different name. Note that this is not restricted to stationary cases, since the initial condition may depend on cctk_time. In that case, one needs to apply the initial conditions at every time step, not only after grid structure changes.

    Thorn Exact offer this feature already. It does so by defining an evolution method that re-applies the initial condition as necessary.

    I suggest two new parameter settings, one for static and one for non-static situations, so that thorn Exact's setting of the evolution method is not necessary any more. These two settings could e.g. be called "reapply-initial-condition-after-grid-structure-changes" and "reapply-initial-condition-at-every-time-step", only much shorter.

  2. Roland Haas reporter
    • removed comment

    I am fine with a different name for the parameters (and being able to schedule after each time step, I had not though of that possibility).

    To give some context: the desire for this methods stems from testing the Bondi infall where I found that I either spend most of my time in Exact setting up the Schwarzschild metric in every step or have to live with the SYNC due to "static" evolution_method causing prolongation and producing non-exact metric values in the buffer regions, which I found undesirable given that I used an exact background metric.

    Making this a parameter of ADMBase would allow us to use any ID thorn with this rather than only Exact which might be a nice feature (maybe for something like a long disk simulation around a NS provided by the Lorene readers). Resetting the data only after a regrid seems to be only safe for "stationary" ie time independent spactimes, hence the choice of keyword. I agree that this is confusing when compared to "static" keyword that already exists.

    How about "regrid-only" and "frozen-ID" for the two choices "reapply-initial-condition-after-grid-structure-changes" and "reapply-initial-condition-at-every-time-step" ?

  3. Log in to comment