Good day to all
Under EOF-Library/tests/interpolationTest
there is a file InterpolationTester.F90 containing
CALL ListInitElementKeyword( Load_h,'Body Force','Field Source')
..............
LoadAtIP = ListGetElementReal( Load_h, Basis, Element, Found, GaussPoint = t )
and a file dg.sif containing
Body Force 1
Field Source = Equals "dg field"
............
Solver 2
Equation = "NameB"
Equation = OpenFOAM2Elmer
Procedure = "OpenFOAM2Elmer" "OpenFOAM2ElmerSolver"
Target Variable 1 = String "dg field"
........
Solver 3
Equation = "ModelPDE"
Variable = "Field"
Procedure = "InterpolationTester" "InterpolationTester"
........
Exported Variable 1 = -dg "dg field"
There is also a file elem.sif just like dg.sif except that elem replaces dg everywhere
and a file ip.sif where ip replaces dg everywhere together with the addition of
+ Interpolate Coordinate = String "ip coordinate"
under Solver 2
and
Exported Variable 4 = -dofs 3 -ip "ip coordinate"
under Solver 3
The question is whether the size of array Load_h is the same in all 3 cases . Is it the same as the default -nodal ?
And if so, are its values the same in all 3 cases ?
Have a nice weekend
Trying to unravel the inner workings of EOF
-
- Site Admin
- Posts: 4843
- Joined: 22 Aug 2009, 11:57
- Antispam: Yes
- Location: Espoo, Finland
- Contact:
Re: Trying to unravel the inner workings of EOF
Hi
Load_h is a structure that holds a lot of stuff. It includes the recipes how to evaluate keywords. Now the fields may be communicated either as nodal fields, *shrinked* dg fields, elemental or ip fields.
Nodal fields are not ideal for interpolation since they have problems at interfaces for discontinuous fields. Hence it is better to have the interpolation points only inside the elements. You can have one point but that is suboptimal in accuracy. Optimal recipe is to use integration points for interpolation. These are the points that guarantee that polynomial is accurately interpolated. However, their number may grow faster than desired. Due to these reasons there is my personal favorite which is the dg field. We are not really using the nodes of the elements but shrink the element such that for some elements the are exactly the same as some integration rules. However, for these we know by construction that their count is always the same as nodes in elements.
Have fun! I was pretty satisfied how nicely the different options came about once the library functionality was supporting them.
-Peter
Load_h is a structure that holds a lot of stuff. It includes the recipes how to evaluate keywords. Now the fields may be communicated either as nodal fields, *shrinked* dg fields, elemental or ip fields.
Nodal fields are not ideal for interpolation since they have problems at interfaces for discontinuous fields. Hence it is better to have the interpolation points only inside the elements. You can have one point but that is suboptimal in accuracy. Optimal recipe is to use integration points for interpolation. These are the points that guarantee that polynomial is accurately interpolated. However, their number may grow faster than desired. Due to these reasons there is my personal favorite which is the dg field. We are not really using the nodes of the elements but shrink the element such that for some elements the are exactly the same as some integration rules. However, for these we know by construction that their count is always the same as nodes in elements.
Have fun! I was pretty satisfied how nicely the different options came about once the library functionality was supporting them.
-Peter
Re: Trying to unravel the inner workings of EOF
Excuse me Peter but I am solving for
Species => Solver % Variable % Values
at the very start of AdvectionDiffusionSolver.
What follows Species is
TempSol => VariableGet( Mesh % Variables, 'Temperature' )
FlowSol => VariableGet( Mesh % Variables, 'Flow Solution' )
which will come from OpenFOAM's NavierStokes as dg variables if I choose
Exported Variable 1 = -dg temperature
(or as ip if I had chosen
Exported Variable 1 = -ip temperature
)
However I believe the above TempSol assumes the variable pointed to is the default -nodal ! Therefore to prevent the program from crashing, I have to find a way to convert the dg variables coming OpenFoam into nodal variables that can be accepted by AdvectionDiffusionSolver.
Regards
Marc
Species => Solver % Variable % Values
at the very start of AdvectionDiffusionSolver.
What follows Species is
TempSol => VariableGet( Mesh % Variables, 'Temperature' )
FlowSol => VariableGet( Mesh % Variables, 'Flow Solution' )
which will come from OpenFOAM's NavierStokes as dg variables if I choose
Exported Variable 1 = -dg temperature
(or as ip if I had chosen
Exported Variable 1 = -ip temperature
)
However I believe the above TempSol assumes the variable pointed to is the default -nodal ! Therefore to prevent the program from crashing, I have to find a way to convert the dg variables coming OpenFoam into nodal variables that can be accepted by AdvectionDiffusionSolver.
Regards
Marc
Re: Trying to unravel the inner workings of EOF
I looked under the Elmer Solver manual section
13. Generic solver utilities
13.3 Exported and derived variables
where it is stated the permutations depend on the variable type:
• -nodal: for node p the degree of freedom is Perm(p)
• -global: no permutation associated
• -elem: for element t the global dof is Perm(t)
• -dg: for element t and node p the global dof is Perm(Element % DGIndexes(p))
• -ip: for element t and integration point p the global dof is Perm(t)+p
-ip has more points than -nodal and -elem has less than -nodal. Unclear to me how I could convert -ip to -nodal.
On the other hand, according to what you stated, -dg has the same number of points as -nodal (the element is just shrunken).
I am not sure why I experienced a segmentation fault with -dg but I suppose I could try mapping node index
Perm(Element % DGIndexes(p))
to
Perm(Element % NodeIndexes(p))
unless you have another suggestion
Yours truly
13. Generic solver utilities
13.3 Exported and derived variables
where it is stated the permutations depend on the variable type:
• -nodal: for node p the degree of freedom is Perm(p)
• -global: no permutation associated
• -elem: for element t the global dof is Perm(t)
• -dg: for element t and node p the global dof is Perm(Element % DGIndexes(p))
• -ip: for element t and integration point p the global dof is Perm(t)+p
-ip has more points than -nodal and -elem has less than -nodal. Unclear to me how I could convert -ip to -nodal.
On the other hand, according to what you stated, -dg has the same number of points as -nodal (the element is just shrunken).
I am not sure why I experienced a segmentation fault with -dg but I suppose I could try mapping node index
Perm(Element % DGIndexes(p))
to
Perm(Element % NodeIndexes(p))
unless you have another suggestion
Yours truly
-
- Site Admin
- Posts: 4843
- Joined: 22 Aug 2009, 11:57
- Antispam: Yes
- Location: Espoo, Finland
- Contact:
Re: Trying to unravel the inner workings of EOF
Hi
Unfortunately the AdvectionDiffusionEquation seems to be created before the increased freedom. You could try to use DG field and modify the code in line 461 to
-Peter
Unfortunately the AdvectionDiffusionEquation seems to be created before the increased freedom. You could try to use DG field and modify the code in line 461 to
Code: Select all
LocalTemperature(1:n) = Temperature( TempPerm(CurrentElement % DGIndexes) )
Re: Trying to unravel the inner workings of EOF
Thank you. I'll try it (and also in StatElecSolver)
Another EOF topic:
Excerpt
Body 1
Target Bodies(2) = l1, l2
Equation = 1
End
of the SIF
results in nBodiesToComm becoming 2 in the excerpt
BList => ListGetIntegerArray( Params, 'Bodies', Found )
nBodiesToComm = SIZE(BList)
of
Elmer2OpenFOAMSolver
Now, if instead, the above SIF excerpt was
Body 1
Target Bodies(1) = l1
Equation = 1
End
Body 2
Target Bodies(1) = l2
Equation = 1
End
where of course nBodiesToComm would now equal 1. would the interpolation tables and interpolated field variables be affected in any way ?
KIndest regards
Another EOF topic:
Excerpt
Body 1
Target Bodies(2) = l1, l2
Equation = 1
End
of the SIF
results in nBodiesToComm becoming 2 in the excerpt
BList => ListGetIntegerArray( Params, 'Bodies', Found )
nBodiesToComm = SIZE(BList)
of
Elmer2OpenFOAMSolver
Now, if instead, the above SIF excerpt was
Body 1
Target Bodies(1) = l1
Equation = 1
End
Body 2
Target Bodies(1) = l2
Equation = 1
End
where of course nBodiesToComm would now equal 1. would the interpolation tables and interpolated field variables be affected in any way ?
KIndest regards
Re: Trying to unravel the inner workings of EOF
I have a 2D fluid and plasma simulation and in order to run it, openfoam needs a 3D mesh with empty patches for the back and front of the domain.
I suppose I also need a 3D mesh for Elmer if it is to communicate with openfoam through EOF. So I extruded a 2D mesh in GMSH and converted it for both Elmer and openfoam. But, how I can I tell Elmer to ignore the back and front ?
Can I simply write
Simulation
Coordinate System = Cartesian 2D
instead of
Simulation
Coordinate System = Cartesian
or would commenting out
Boundary Condition 1
Target Boundaries(1) = n ! the back and front
.....
End
be sufficient ?
Sincerely yours
I suppose I also need a 3D mesh for Elmer if it is to communicate with openfoam through EOF. So I extruded a 2D mesh in GMSH and converted it for both Elmer and openfoam. But, how I can I tell Elmer to ignore the back and front ?
Can I simply write
Simulation
Coordinate System = Cartesian 2D
instead of
Simulation
Coordinate System = Cartesian
or would commenting out
Boundary Condition 1
Target Boundaries(1) = n ! the back and front
.....
End
be sufficient ?
Sincerely yours
-
- Site Admin
- Posts: 4843
- Joined: 22 Aug 2009, 11:57
- Antispam: Yes
- Location: Espoo, Finland
- Contact:
Re: Trying to unravel the inner workings of EOF
Hi
EOF does not probably make sense in 2D. Also it does not care about boundaries, it only maps the fields in the 3D domains. I would think that you can use the standard way of Elmer to have modules active on only given domains and the fields would be interpolated accordingly.
-Peter
EOF does not probably make sense in 2D. Also it does not care about boundaries, it only maps the fields in the 3D domains. I would think that you can use the standard way of Elmer to have modules active on only given domains and the fields would be interpolated accordingly.
-Peter
Re: Trying to unravel the inner workings of EOF
OK. Let's forget about EOF and openfoam and concentrate on Elmer alone. It can solve say a Poisson equation in 2D using
Coordinate System = Cartesian 2D
on a 2D mesh , but would I get the same result by extruding the 2D mesh in 3D from z=0 to z=1 so that the z=1 plane mesh is a carbon copy of the z=0 plane and with no points in the resultant 3D mesh for 0 < z < 1
and by simply commenting out
Boundary Condition 1
Target Boundaries(1) = n ! z=0 and z=1 planes
Would that ensure that the solved field variable at the z=1 plane is a carbon copy of the values on the z=0 plane ?
Best
Marc
Coordinate System = Cartesian 2D
on a 2D mesh , but would I get the same result by extruding the 2D mesh in 3D from z=0 to z=1 so that the z=1 plane mesh is a carbon copy of the z=0 plane and with no points in the resultant 3D mesh for 0 < z < 1
and by simply commenting out
Boundary Condition 1
Target Boundaries(1) = n ! z=0 and z=1 planes
Would that ensure that the solved field variable at the z=1 plane is a carbon copy of the values on the z=0 plane ?
Best
Marc