Remove m_cell_centered_data from multifab map #5322
Conversation
Source/Diagnostics/BTDiagnostics.cpp
Outdated
| @@ -519,7 +519,8 @@ BTDiagnostics::DefineCellCenteredMultiFab(int lev) | |||
| #else | |||
| const int ncomps = static_cast<int>(m_cellcenter_varnames.size()); | |||
| #endif | |||
| WarpX::AllocInitMultiFab(m_cell_centered_data[lev], ba, dmap, ncomps, amrex::IntVect(ngrow), lev, "cellcentered_BTD", 0._rt); | |||
| m_cell_centered_data[lev] = std::make_unique<amrex::MultiFab>(ba, dmap, ncomps, amrex::IntVect(ngrow)); | |||
There was a problem hiding this comment.
Why not use MultiFabRegister::alloc_init and ::erase?
There was a problem hiding this comment.
So far, we deallocated m_cell_centered_data[lev] when the BTDiagnostics is deallocated. We do not want to change that behavior here in terms of how long the lifetime goes.
Deallocation of each BTDiagnostics variable currently probably (to verify with @RevathiJambunathan) happens only at the end of the simulation. If that is true, we do not need even need to call ::erase when a station is done. If there is an earlier deallocation of BTDiagnostics (proably should be) or more logic in ~BTDiagnostics or when a station is fully done, then we should call ::erase at those points.
For the name we put in the MultiFabRegister, we should create a unique name by combining:
- a clear BTD prefix and
- the current BTD diagnostics name (from the inputs) and
- the station it works on (usually called
i_buffer, if I am not mistaken).
This will be nice, because we can now more easily track the overhead of BTD diags.
There was a problem hiding this comment.
The lifetime of the diagnostics is the same as the lifetime of the WarpX class so the erase is not needed.
Prepares to remove `WarpX` class altogether from here.
The back transformed data diagnostics generates a MultiFab,
m_cell_centered_data, to hold cell centered data when the output data is being generated. This was being added to the old version of the MultiFab map. Since the data is temporary and since there could be multiple copies of the MultiFab (if there are multiple BTD diagnostics), it doesn't make sense to have the MultiFab in the registry. This PR changes the code so that the MultiFab is directly allocated.With this PR, the last MultiFab is removed from the old MultiFab map, so it can be removed in a subsequent PR.
Follow-up to #5230