Add InitialBoundaryCondition (IBC) struct.#477
Add InitialBoundaryCondition (IBC) struct.#477baperry2 merged 99 commits intoAMReX-Combustion:developmentfrom
Conversation
|
@esclapez - I created a pull request into this branch with the changes for freeProbParm. After you approve that, let's create a list of changes that users will need to make as a result of this PR, then merge this! |
add freeProbParm function to all case cpp files
|
@baperry2 I'm adding a tweak to address Marc's comment. I actually removed the ability to have partial coverage of the EB face with a EBtype different from the default in the EBInflow implementation. With this tweak, |
|
As we get ready to merge, @marchdf and @dmontgomeryNREL suggest that we create a numbered release before and after to help users manage the breaking changes. Before you had been doing releases numbers as YEAR.MONTH (like AMReX), but we haven't released anything since 23.11. We could also move to the standard MAJOR.MINOR.PATCH numbering scheme (like AMR-Wind). @esclapez and @drummerdoc: any thoughts on this and how else to help people manage versioning especially with breaking changes as we gain more users? |
|
Good idea with the versioning. I'm ok using the month.year scheme and there just being missing months...maybe add a note to any version that skips months/years just to be clear. |
|
I was thinking of indeed releasing a new version because it's been a while. The YY.MM format makes sense with frequent releases but there hasn't been a strong motivation to do so with development slowing down after ECP. So maybe switching to MAJOR.MINOR.PATCH would make more sense. I was trying to find a way to detect at compile time if the user still has a |
|
How about releasing one last release in the MM.YY format before this merge, then releasing this version as Autodetecting and pointing to documentation when |
|
@esclapez, @drummerdoc, and @ThomasHowarth: I will merge this later this week and release the versions as described above unless anyone objects. |
4 participants
Same principle as in PeleC but for kernels only at this point:
the initial and boundary condition kernels are gathered in a struct inheriting from a default, such that the user only has to override the ones he really need. It offers more flexibility to introduce change without breaking backward compatibility in the future.
Only a few Exec updated for now and starting with a draft PR, let's discuss any (other) breaking changes in those kernels @baperry2 .
Following the discussion in #467, I've removed
nAuxfrominitdataand addeds_inwhich can be used to do some same-face inflow/outflow tricks.We can probably also move some other functions in there (EBGeom, UserDefinedDerived, ExtSourceTerm, ...) although I'm not sure what get copied to the device when a static kernel from the struct is called within an AMReX macro+lambda.