Implement inherited MOOSE variable classes to shadow OpenFOAM fields and function objects#66
Conversation
…adowing with basic test
|
I think we should consider whether to use a specialised |
…r variable shadowing
hsaunders1904
left a comment
hsaunders1904
left a comment
There was a problem hiding this comment.
This looks great! A much nicer interface, I think. When are we planning on removing the old way of performing the transfers? I guess when the BCs are done?
Do you have a clear idea of how we would extend the existing FoamVariableField code for volumetric transfers?
| # Additional special case targets should be added here | ||
|
|
||
| # Add foam modules | ||
| # TODO: Reorganise build: consider single mk for all OpenFOAM modules |
There was a problem hiding this comment.
Shall we open an issue for this, rather than leaving it as a TODO?
There was a problem hiding this comment.
I will add an issue but would rather leave to todo's in, so I get a reminder when I am doing it
| #include "MooseTypes.h" | ||
| #include "FoamMesh.h" | ||
|
|
||
| class FoamVariableField : public MooseObject |
There was a problem hiding this comment.
Would FoamFieldVariable be a better name here? It's a MOOSE variable representing an OpenFOAM field, so it feels like "foam" and "field" belong next to one-another.
There was a problem hiding this comment.
I was thinking that when I add handling of vectors at some point I will change it to FoamScalarField/FoamVectorField to mirror volScalarField etc. Also there is a MOOSE class called MooseVariableField so the analogy may be useful.
| FoamVariableField::createMooseVariable(std::string name, const InputParameters & params) | ||
| { | ||
| // TODO: Add other parameters from variable instantiations such as Boundary restrictions | ||
| auto & problem = getMooseApp().feProblem(); |
There was a problem hiding this comment.
Should we be checking this a FoamProblem?
There was a problem hiding this comment.
We can, but by this point it would be checked already by the action syntax, so probably fine. Depends on how defensive we need to be.
| [] | ||
| [Problem] | ||
| type = FoamProblem | ||
| # Take the boundary temperature from OpenFOAM and set it on the MOOSE mesh. |
There was a problem hiding this comment.
Is this comment useful anymore?
There was a problem hiding this comment.
I will fix this in the tests PR.
| #include "SystemBase.h" | ||
| #include "dictionary.H" | ||
| #include "functionObject.H" | ||
| // #include "wallHeatFlux.h" |
There was a problem hiding this comment.
I will fix this in the tests PR.
|
I am deprecating the old syntax in a separate PR I hope to create by the end of the day. For volumetric transfers, that is a question of rewriting |
|
I will merge this now to the interim branch and make fixes to the most recent branch. |
mattfalcone1997
merged commit bce2c98
into
aurora-multiphysics:generalise_bcs_transfer
2 participants
Summary
Currently, Hippo transfers fields explicitly to be imposed as temperatures or heat fluxes in MOOSE. This PR generalises part of this by allowing OpenFOAM fields (such as temperature
T) and function objects (such as heat fluxwallHeatFlux) to be shadowed by MOOSE variables. The second part of this will be to generalise the imposition of BCs in OpenFOAM using MOOSE input file syntax.Related Issue
Resolves #43
Checklist
volScalarFieldsand function objects that returnvolScalarFields.