Skip to content

Conversation

jmsexton03
Copy link
Contributor

Summary

This PR adds a new EB2::Build variant that accepts a Vector<Geometry> to explicitly specify the geometry at each AMR level. Unlike the existing Build function that generates coarse levels through automatic coarsening, this version constructs EB data directly from the provided geometries at each level. This is useful for applications that need precise control over domain specification at each AMR level or when coarse levels are not simple coarsenings of the finest level.

Additional background

Checklist

The proposed changes:

  • fix a bug or incorrect behavior in AMReX
  • add new capabilities to AMReX
  • changes answers in the test suite to more than roundoff level
  • are likely to significantly affect the results of downstream AMReX users
  • include documentation in the code and/or rst files, if appropriate

- Builds each level directly from GeometryShop at native resolution
- No coarsening needed - supports general refinement ratios
- Populates m_gslevel, m_geom, m_domain, m_ngrow for all levels
This reverts commit 608d86e.

ngrow should not be based on the level
int num_coarsen_opt = NumCoarsenOpt());

This version takes a :cpp:`Vector<Geometry>` where each element corresponds to
the geometry of a specific AMR level, ordered from finest (index 0) to coarsest.
Copy link
Member

Choose a reason for hiding this comment

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

Does the order matter?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't think it matters in terms of 0 being finest, would it be better to not mention order here? The other Build only has the finest Geometry and then builds coarser, I think, but for this it's just using the order that comes in.

Copy link
Member

Choose a reason for hiding this comment

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

The thing is AmrMesh stores Geometry in the opposite order. We should try to accept unordered Geometry objects. Internally, we could make a copy and then sort it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I see, that sounds like a better approach then assuming a certain order. Would you sort on CellSize or something else? Is there an example of sorting somewhere else (I only saw << >> and = as overloaded operators)

    [[nodiscard]] AMREX_GPU_HOST_DEVICE AMREX_FORCE_INLINE
    Real CellSize (int dir) const noexcept { return dx[dir]; }

Copy link
Member

Choose a reason for hiding this comment

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

Make the function take Vector<Geometry> geom instead of Vector<Geometry> const& geom. Then

std::sort(geom.begin(), geom.end(), [] (Geometry const& a, Geometry const& b) { return a.Domain().numPts() > b.Domain().numPts(); });

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the code and for finding that lack of generality. I've pushed what I think fixes it.

@WeiqunZhang WeiqunZhang merged commit e92641d into AMReX-Codes:development Oct 14, 2025
73 checks passed
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.

2 participants