Cryptic error message when using in_memory

[Stephen Biggs-Fox]

When running with in_memory = .true., I get the following error message:

 INFO: changing force_maxwell_reinit or in_memory  after calling initial_values_
 overrides_type will almost certainly cause  segmentation faults.

My run did not complain about seg faults. However, it did go badly wrong: time increased monotonically for a while an then started oscillating about zero!

It would appear that I have made a mistake in the input file. However, after reading the input parameters wiki page and the error message above, I'm none the wiser as to what I've done wrong or how to fix it.

At the very least, the error message and input parameters documentation needs to be improved. I have not yet looked at the code so I'm not yet sure how to improve the error message nor how / if the code itself needs to be fixed / improved.

[Joseph Parker]

Thanks Steve - that is pretty cryptic! I'm not familiar with this bit of code. What does the in_memory flag do?

[Stephen Biggs-Fox]

When re-initialising a nonlinear run due to CFL condition, the default is to write dist fn., fields, etc. to file, re-initialise, then read them in from file again. The in_memory flag says don't write to file, just keep stuff in memory, i.e. should be an optimisation.

[Stephen Biggs-Fox]

Changing back to in_memory = .false. avoids the weird behaviour with non-monotonic time, but the error message is still given. Therefore, it looks like in_memory may have a code problem, but the error message appears to be coming from something else. The wording of the error message still needs to be improved. Other things I changed just before this happened (i.e. candidates for the source of the error message) include esv, chop_side, clean_init, and immediate_reset.

[Joseph Parker]

immediate_reset determines whether or not gs2 completes a timestep when the CFL condition is broken. I can imagine setting this .false. might not be compatible (yet) with in_memory = .true.. Are you using immediate_reset=.false.? If so, do you see the same problem if you set immediate_reset=.true.?