Skip to content

Conversation

@ZedThree
Copy link
Member

@ZedThree ZedThree commented Jan 9, 2026

Supports #3242

Note these don't actually add Z parallelisation, just let us handle it correctly in various places

  • Mesh::GlobalZ for global Z index in [0, 1]
  • Mesh::getNZPE/getZProcIndex for Z processor info
  • bout::fft::checkZSerial to guard routines using FFT

These also make a lot of code more consistent between the directions

Copy link
Contributor

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

clang-tidy made some suggestions

d7919 and others added 10 commits January 9, 2026 14:34
Tests are updated because `FakeMesh` has `GlobalZ(z) == z`. This is completely
arbitrary, we could have a `GlobalZ` definition that matches `BoutMesh` (`z / nz`)
then we wouldn't need to change the tests, but this way is a bit clearer what
we're testing.
Also make related methods all `const`
These are just the `BoutReal` overloads of the equivalent `getGlobal?Index` methods
dschwoerer
dschwoerer previously approved these changes Jan 13, 2026
Solver* UNUSED(solver))
: Laplacian(opt, loc, mesh_in), A(0.0), C(1.0), D(1.0) {

bout::fft::checkZSerial(*localmesh, "`tri` inversion");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be clearer to name this assertZSerial()?

ASSERT2(var.getMesh()->getNguard(direction) >= nGuards);
ASSERT2(direction == DIRECTION::Z); // Only in Z for now
ASSERT2(stagger == STAGGER::None); // Staggering not currently supported
ASSERT2(bout::utils::is_Field3D_v<T>); // Should never need to call this with Field2D
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't that known at compile time?
So there is no runtime overhead, to have this check always included?

(Same for several of the above)

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, but checking at compile implies that we need to not build some of these for certain types, which might complicate the various macros. At any rate, it's something for a different PR!

[skip ci]

Co-authored-by: David Bold <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants