-
Notifications
You must be signed in to change notification settings - Fork 421
Add Build with Explicit Multi-Level Geometry for EB #4714
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
Add Build with Explicit Multi-Level Geometry for EB #4714
Conversation
- 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. |
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.
Does the order matter?
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.
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.
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.
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.
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.
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]; }
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.
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(); });
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.
Thanks for the code and for finding that lack of generality. I've pushed what I think fixes it.
Summary
This PR adds a new
EB2::Build
variant that accepts aVector<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: