Split ParthenonManager Init

[pgrete]

PR Summary

As mentioned in #409 this split allows to set the app_inputs (e.g., refinement criteria or problem generator) from the input file by splitting the environment init (MPI, Kokkos, parsing arguments) from the package processing and mesh initialization.

I kept the original interface so it shouldn't break existing code but that could also be removed.

I'm looking for feedback now before updating the documentation and potentially examples (making sure this goes in the right direction).

I didn't derive from #385 as my impression was that there was a different intention (which we may also follow here, i.e., make a three way split -> .e.g, InitEnv, ParseArgs, InitMesh)

Closes #409

PR Checklist

• Code passes cpplint
• New features are documented.
• Adds a test for any bugs fixed. Adds tests for new features.
• Code is formatted
• Changes are summarized in CHANGELOG.md
• (@lanl.gov employees) Update copyright on changed files

[JoshuaSBrown]

This looks like an improvement to me, I'm normally in favor of breaking up logic into smaller more manageable chunks. However, I don't have a good grasp yet on what you are trying to accomplish with this. #409 issue mentions allowing flexibility during runtime for the choice of problem generator, I'm not yet sure what this would look like with the work done in this pr. I defer to the physics folks.

[pgrete]

This looks like an improvement to me, I'm normally in favor of breaking up logic into smaller more manageable chunks. However, I don't have a good grasp yet on what you are trying to accomplish with this. #409 issue mentions allowing flexibility during runtime for the choice of problem generator, I'm not yet sure what this would look like with the work done in this pr. I defer to the physics folks.

Have a look at https://gitlab.com/theias/hpc/jmstone/athena-parthenon/athenapk/-/blob/pgrete/pack-in-one/src/main.cpp#L36
This was previously not possible as pinput was parsed/populated in Init with all the other stuff (so setting custom function and problem generator based in configurations present in the input file required additional workarounds)

[Yurlungur]

Thanks for doing this. We recently hit a use case where we wanted to do the same thing in riot.

Is there any documentation for parthenon manager? If so we should update that and add a changelog.

[pgrete]

Thanks for doing this. We recently hit a use case where we wanted to do the same thing in riot.

Is there any documentation for parthenon manager? If so we should update that and add a changelog.

If there's one, we probably want to extend it or otherwise add one.
I'm happy to do so (in this PR) I just wanted to make sure that people agree that this looks okay (before writing a documentation for an interface that would change during review).

[Yurlungur]

I'm happy to do so (in this PR) I just wanted to make sure that people agree that this looks okay (before writing a documentation for an interface that would change during review).

Makes sense. I think this is worth doing.

[JoshuaSBrown]

This looks like an improvement to me, I'm normally in favor of breaking up logic into smaller more manageable chunks. However, I don't have a good grasp yet on what you are trying to accomplish with this. #409 issue mentions allowing flexibility during runtime for the choice of problem generator, I'm not yet sure what this would look like with the work done in this pr. I defer to the physics folks.

Have a look at https://gitlab.com/theias/hpc/jmstone/athena-parthenon/athenapk/-/blob/pgrete/pack-in-one/src/main.cpp#L36
This was previously not possible as pinput was parsed/populated in Init with all the other stuff (so setting custom function and problem generator based in configurations present in the input file required additional workaround.

Thanks for the link, I understand now. Yes I am onboard.

[pgrete]

Added doc (no code changes), so this should be ready for final review and approval.

[JoshuaSBrown]

Thanks @pgrete!

[Yurlungur]

Thanks, @pgrete !