Skip to content

Conversation

ax3l
Copy link
Member

@ax3l ax3l commented Sep 11, 2025

Simplify calls t other MultiFabRegister by adding descriptive member variables to ablastr::fields::Direction as well as string conversion. Fix internal values for dir to make sense in other dimensions than 3D, too.

Isolated from #6154

To Do

  • improve implementation
  • update usage / call sites RZ/RCylindrical/RSpherical: Direction{0} -> 'r', etc.
  • update usage / call sites Cartesian: Direction{0} -> 'x', etc. where explicitly Cartesian code is written

@ax3l ax3l added component: core Core WarpX functionality component: Python Python layer component: ABLASTR components shared with other PIC codes labels Sep 11, 2025
@ax3l ax3l force-pushed the topic-py-dimensions-nice branch from 71462b9 to 90612cf Compare September 12, 2025 00:06
@ax3l ax3l force-pushed the topic-py-dimensions-nice branch 3 times, most recently from 05a4fd4 to 2a50ef1 Compare September 12, 2025 02:40
@ax3l ax3l changed the title Direction: Descriptive Static Member Variables MF Register Direction: Descriptive Members Sep 12, 2025
@ax3l ax3l force-pushed the topic-py-dimensions-nice branch 2 times, most recently from d356d4c to a72f177 Compare September 12, 2025 04:01
@ax3l ax3l force-pushed the topic-py-dimensions-nice branch from d66a8b1 to 6d31ecf Compare September 12, 2025 05:56
@ax3l
Copy link
Member Author

ax3l commented Sep 12, 2025

@EZoni interesting observation: the 1D test fails to build but the Azure Pipelines Build step shows as green.
image

Let us check why. It is good to error out immediately so one does not see a confusing follow-up error on compile issues.

@@ -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);
Copy link
Member Author

@ax3l ax3l Sep 12, 2025

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?

@ax3l ax3l force-pushed the topic-py-dimensions-nice branch from b3138f6 to 38f3597 Compare September 12, 2025 06:41
@ax3l ax3l mentioned this pull request Sep 12, 2025
4 tasks
Copy link
Member

@dpgrote dpgrote left a 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=")
Copy link
Member Author

@ax3l ax3l Sep 12, 2025

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...

Copy link
Member

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.

Copy link
Member

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?

Copy link
Member Author

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: ABLASTR components shared with other PIC codes component: core Core WarpX functionality component: Python Python layer
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants