-
Notifications
You must be signed in to change notification settings - Fork 223
MF Register Direction: Descriptive Members #6162
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: development
Are you sure you want to change the base?
Conversation
71462b9
to
90612cf
Compare
05a4fd4
to
2a50ef1
Compare
d356d4c
to
a72f177
Compare
d66a8b1
to
6d31ecf
Compare
@EZoni interesting observation: the 1D test fails to build but the Azure Pipelines Let us check why. It is good to error out immediately so one does not see a confusing follow-up error on compile issues. |
Source/Diagnostics/BTDiagnostics.cpp
Outdated
@@ -582,23 +582,23 @@ BTDiagnostics::InitializeFieldFunctors (int lev) | |||
m_cell_center_functors.at(lev).size()); | |||
for (int comp=0; comp<m_cell_center_functors_at_lev_size; comp++){ | |||
if ( m_cellcenter_varnames[comp] == "Ex" ){ | |||
m_cell_center_functors[lev][comp] = std::make_unique<CellCenterFunctor>(fields.get(FieldType::Efield_aux, Direction{0}, lev), lev, m_crse_ratio); | |||
m_cell_center_functors[lev][comp] = std::make_unique<CellCenterFunctor>(fields.get(FieldType::Efield_aux, Direction::x, lev), lev, m_crse_ratio); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like the RCylinder code (accidentially?) compiles/uses this (very Cartesian-looking?) code section:
FAILED: [code=1] CMakeFiles/lib_rcylinder.dir/Source/Diagnostics/BTDiagnostics.cpp.o
/usr/bin/ccache /usr/bin/c++ -DABLASTR_USE_FFT -DAMREX_SPACEDIM=1 -DAMReX_FFTW_OMP=1 -DWARPX_DIM_RCYLINDER -DWARPX_QED -DWARPX_STATIC_DEFINE -DWARPX_USE_FFT -DWARPX_USE_OPENPMD -DWarpX_FFTW_OMP=1 -Dlib_rsphere_EXPORTS -I/home/vsts/work/1/s/Source -I/home/vsts/work/1/s/build/Source -I/home/vsts/work/1/s/build/_deps/fetchedopenpmd-src/include -I/home/vsts/work/1/s/build/_deps/fetchedopenpmd-build/include -I/home/vsts/work/1/s/build/_deps/fetchedpicsar-src/multi_physics/QED/include -I/home/vsts/work/1/s/build/_deps/fetchedamrex-src/Tools/C_scripts -isystem /home/vsts/work/1/s/build/_deps/fetchedamrex-src/Src/Base -isystem /home/vsts/work/1/s/build/_deps/fetchedamrex-src/Src/Base/Parser -isystem /home/vsts/work/1/s/build/_deps/fetchedamrex-src/Src/Boundary -isystem /home/vsts/work/1/s/build/_deps/fetchedamrex-src/Src/AmrCore -isystem /home/vsts/work/1/s/build/_deps/fetchedamrex-src/Src/LinearSolvers -isystem /home/vsts/work/1/s/build/_deps/fetchedamrex-src/Src/LinearSolvers/MLMG -isystem /home/vsts/work/1/s/build/_deps/fetchedamrex-src/Src/Particle -isystem /home/vsts/work/1/s/build/_deps/fetchedamrex-src/Src/FFT -isystem /home/vsts/work/1/s/build/_deps/fetchedamrex-build -isystem /usr/lib/x86_64-linux-gnu/openmpi/include -isystem /usr/lib/x86_64-linux-gnu/openmpi/include/openmpi -g1 -Wall -Wextra -Wpedantic -Wshadow -Woverloaded-virtual -Wunreachable-code -O3 -DNDEBUG -std=c++17 -fPIC -fopenmp -finline-limit=43210 -MD -MT CMakeFiles/lib_rcylinder.dir/Source/Diagnostics/BTDiagnostics.cpp.o -MF CMakeFiles/lib_rcylinder.dir/Source/Diagnostics/BTDiagnostics.cpp.o.d -o CMakeFiles/lib_rcylinder.dir/Source/Diagnostics/BTDiagnostics.cpp.o -c /home/vsts/work/1/s/Source/Diagnostics/BTDiagnostics.cpp
/home/vsts/work/1/s/Source/Diagnostics/BTDiagnostics.cpp: In member function ‘virtual void BTDiagnostics::InitializeFieldFunctors(int)’:
/home/vsts/work/1/s/Source/Diagnostics/BTDiagnostics.cpp:585:130: error: ‘x’ is not a member of ‘ablastr::fields::Direction’
585 | m_cell_center_functors[lev][comp] = std::make_unique<CellCenterFunctor>(fields.get(FieldType::Efield_aux, Direction::x, lev), lev, m_crse_ratio);
| ^
will simply keep the general write style as before and revert this.
@dpgrote is this intentional or maybe lacking an #ifdef
?
This reverts commit 6d31ecf.
b3138f6
to
38f3597
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea!
return mf_name( | ||
name | ||
.append("[") | ||
.append("[dir=") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@roelof-groenewald @RemiLehe @dpgrote just highlighting that this is a breaking change if someone uses the "raw old strings" still in Python instead of the APIs we defined a year ago. I do not think someone does and our wrappers are mostly used anyway, which do the right thing...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@n01r I think that you may have some scripts that use this. Just flagging the breaking change here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should the use of the internal names be deprecated?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, ideally. This is mostly to make sure that list()
looks understandable.
Do we use internal names still somewhere?
Simplify calls t other
MultiFabRegister
by adding descriptive member variables toablastr::fields::Direction
as well as string conversion. Fix internal values fordir
to make sense in other dimensions than 3D, too.Isolated from #6154
To Do
Direction{0} -> 'r'
, etc.Direction{0} -> 'x'
, etc. where explicitly Cartesian code is written