Skip to content
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

One way of fixing UDF fillpatches for face quantities (mac velocities) #1084

Closed
wants to merge 6 commits into from

Conversation

mbkuhn
Copy link
Contributor

@mbkuhn mbkuhn commented May 30, 2024

Summary

Using template arguments to modify the boundary index checks for face quantities. Ended up needing a decent amount of new function / type declarations, though, and I'm not sure how best to use the loop within fillpatch_sibling_fields now that each physbc has a different type.

Pull request type

  • Bugfix
  • Feature
  • Code style update (formatting, renaming)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • Documentation content changes
  • Other (please describe):

Checklist

The following is included:

  • new unit-test(s)
  • new regression test(s)
  • documentation for new capability

This PR was tested by running:

  • the unit tests
    • on GPU
    • on CPU
  • the regression tests
    • on GPU
    • on CPU

Additional background

This may not be the best way to do it... it may make things harder when we try to improve the UDFs. Obviously, this is starting off sloppy and will need a thorough pass through and probably unit tests added as well.

Issue Number: #1076

@mbkuhn mbkuhn requested a review from marchdf May 30, 2024 17:35
@mbkuhn
Copy link
Contributor Author

mbkuhn commented May 30, 2024

Running the rankine test with this branch give the following output (relevant parts only)

// Fill mac velocities using velocity BCs
sibling fields FPSL dir i = 0 (umac)
Rankine.H op: filling 10.73181747 at i=-1
Rankine.H op: filling 10.13957005 at i=41
sibling fields FPSL dir i = 1 (vmac)
Rankine.H op: filling 1.016180833 at i=-1
Rankine.H op: filling 0.5357916479 at i=40
sibling fields FPSL dir i = 2 (wmac)
Rankine.H op: filling 0 at i=-1
Rankine.H op: filling 0 at i=40

@@ -11,6 +11,17 @@

namespace amr_wind {

namespace {
int CC_idx(int /* idir */)
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if for some of these we can use stuff in: https://github.com/Exawind/amr-wind/blob/main/amr-wind/utilities/DirectionSelector.H#L56. Kinda like we do for IndexSelector

Copy link
Contributor Author

Choose a reason for hiding this comment

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

took some inspiration from there.

@@ -50,6 +64,9 @@ struct FieldBCNoOp
constexpr explicit FieldBCNoOp(const Field& /*unused*/) {}

FunctorType operator()() const { return *this; }
FunctorXType opfx() const { return *this; }
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we template this so we don't have repeats? template <T> T opf() ?

@@ -169,9 +186,10 @@ struct DirichletOp
}

// Check if the point in question is on the boundary
int mod_bigEnd = domain_box.bigEnd(idir) + IdxOp(idir);
Copy link
Contributor

Choose a reason for hiding this comment

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

const and maybe a more descriptive name? bigEnd_depending_on_if_you_are_cc_or_fc ;-) obv not that either.


explicit FieldBCDirichlet(const Field& fld) : m_field(fld) {}

inline FunctorType operator()() const { return FunctorType(m_field); }
inline FunctorXType opfx() const { return FunctorXType(m_field); }
Copy link
Contributor

Choose a reason for hiding this comment

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

I gotta think there's a way to template these... template <typename T> T opf() const {return T(m_field);}. Can you see if that's possible?

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 didn't include FunctorType in the templating but that is definitely possible too.

@@ -217,7 +241,10 @@ struct BCOpCreator
{
using InflowOpType = typename InflowOp::DeviceType;
using WallOpType = typename WallOp::DeviceType;
using FunctorType = DirichletOp<InflowOpType, WallOpType>;
using FunctorType = DirichletOp<InflowOpType, WallOpType, &CC_idx>;
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we don't need CC_idx I think we can leave it empty and use a default.

@@ -235,6 +262,27 @@ struct BCOpCreator
m_wall_op.device_instance()};
}

inline FunctorXType opfx() const
Copy link
Contributor

Choose a reason for hiding this comment

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

with the templating I think we consolidate all these.

amrex::PhysBCFunct<amrex::GpuBndryFuncFab<Functor>> physbc(
m_mesh.Geom(lev), bcrec, bc_functor());
amrex::PhysBCFunct<amrex::GpuBndryFuncFab<FunctorX>> physbcx(
m_mesh.Geom(lev), bcrec, bc_functor_x());
Copy link
Contributor

Choose a reason for hiding this comment

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

What would be neat here is to keep the for loop and instead do bc_functor_f(i). Or maybe it becomes easier with the templating.

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'm having a hard time getting the loop to work. The problem is that the type of physbcx depends on the direction, in addition to the bc_functor type. I have templatized the FunctorF type, but the template argument has to be a const expression, so it cannot be according to the index i. Making bc_functor output different things depending on an input argument is a problem, too, because each output would be a different type. I also can't put the physbcs into a vector because they're different types. Not sure if there is a way forward here.

Copy link
Contributor

Choose a reason for hiding this comment

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

ah. yeah I see the issue. I need to think about this....

@marchdf
Copy link
Contributor

marchdf commented May 31, 2024

Nice work! I left a bunch of comments/thoughts/things to try out. LMK if you want help with these.

I think this mostly takes care of the first bit: getting the right indices to be used in the UDF op. The comments I had in the original issue were more focused on defining a different op for the faces. I am not sure we want to go down that road but it's the "right thing to do" eventually. Though again, getting those precise details right is probably only important for BDS and the mac vel in the ghost cells.

Comment on lines +296 to +302
/*
for (int i = 0; i < static_cast<int>(mfabs.size()); i++) {
amrex::FillPatchSingleLevel(
*mfabs[i], nghost, time, {ffabs[i]}, {time}, 0, 0, 1,
m_mesh.Geom(lev), physbc, i);
}
*/

Check notice

Code scanning / CodeQL

Commented-out code Note

This comment appears to contain commented-out code.
@marchdf
Copy link
Contributor

marchdf commented Jun 11, 2024

This is done in #1093

@marchdf marchdf closed this Jun 11, 2024
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