(#543) MAXP should not be hardwired in the SETUP block #544
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Type of PR:
Bug fix
Description:
Fix to #543 and #465.
For #543, the problem is that MAXP should no longer be hardwired in the compile-time configuration block. Instead, it can be specified at runtime using
In phantom the memory allocation is automatic as the number of particles is read from the dump file header. This should be ideally be done automatically also in phantomsetup but this is currently not the case, as memory allocation is done before entering the setpart routine
For #465 the issue was that the conserved variables were not initialised before calling derivs. This was working in previous code versions because a call to prim2consall was inserted directly into the derivs routine. This was commented out because it broke the phantomNR implementation. Indeed, we should not be doing prim2cons there because this overrides the input conservative variables. Instead, I have now inserted a call to prim2consall inside get_derivs_global so that when get_derivs_global is called during relax_star the metric and conserved quantities are computed correctly.
Testing:
Did you run the bots? no
Did you update relevant documentation in the docs directory? no