-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Remove NSFV Action and NSFV component, use Physics #27951
base: next
Are you sure you want to change the base?
Conversation
Job Documentation on 805ae63 wanted to post the following: View the site here This comment will be updated on new commits. |
cd222c6
to
4e007dd
Compare
c1e4cfc
to
bd99916
Compare
Are the TH area users ready for this? |
Note that the old syntax remains completely functional. It's just the backend that changes (towards something that uses mostly the same code, just organized differently). |
Public app failure is fake |
Oh nice 👍 |
bd99916
to
c783c89
Compare
Job Coverage on 805ae63 wanted to post the following: Framework coverageCoverage did not change Modules coverageNavier stokes
Thermal hydraulics
Full coverage reportsReports
This comment will be updated on new commits. |
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 want to discuss
Had to regold because using a single physics for both components and the two components were using different advection methods. This is not one of the block restricted parameters.
The other solution would have been to use two physics. This would necessitate different variable names at the moment. There were some work on merging physics together
It is possible, it's also quite a bit of code to achieve something that so far is not really needed
In particular the part about needing different variables if needing more than one physics. I just want to understand any limitations before tighter integration between components and physics. But the change to this test is probably fine.
expect_err = 'rho: The density in the boussinesq term is not constant!' | ||
requirement = 'The system should throw an error if the density is not a constant functor in case of Boussinesq treatment.' | ||
valgrind = 'none' | ||
issues = '#19742' | ||
# New physics cannot support this because we want properties forwarded from fluid properties to work |
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 quite understand. So the Physics version is not going to take density as a functor?
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.
No the test for detecting whether a functor is constant doesn't work reliably. It just calls isConstant but many constants are not created in ConstantFunctors
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.
So how does Physics affect this? And does this test make sense to exist? Do we just need to improve isConstant
somehow?
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.
Do we just need to improve isConstant somehow?
I dont see an easy way. Save for maybe evaluating it all over the mesh to check.
So how does Physics affect this?
I dont want to limit incompressible flow to not using the FP properties and the GFFP. I ll give it another try to see if I can re-enable this.
Unless we start changing the block restrictions of created objects, I don't see how we could not use different variable names. The physics create block restricted variables and UOs. If we have two physics, we would need them to modify the block restriction. My preference is a single physics, with block restricted parameters on the components that fill the maps I have been creating to hold the parameters |
Ok, I'm good with these changes, so just checking for any dissent by @licharlot or @tanoret before approval. |
More verbose block restriction error refs idaholab#25642
check the inputs before forming a map refs idaholab#25642
Remove FlowComponentNS: covered by FileMeshPhysicsComponent refs idaholab#25642
Had to regold because using a single physics for both components and the two components were using different advection methods. This is not one of the block restricted parameters. The other solution would have been to use two physics. This would necessitate different variable names at the moment. There were some work on merging physics together It is possible, it's also quite a bit of code to achieve something that so far is not really needed refs idaholab#25642
6ec74f9
to
f2cd40c
Compare
The new default is true, as we have to assume the user does not want an extra multiplication by porosity, as most PGH models do not require it refs idaholab#25642
f2cd40c
to
805ae63
Compare
let's go? |
Looks good to me. Thanks for adding the transition tutorial. |
refs #25642