Trying to unravel the inner workings of EOF

Mesh generators, CAD programs, and other tools
spacedout
Posts: 177
Joined: 30 Mar 2020, 23:27
Antispam: Yes

Trying to unravel the inner workings of EOF

Post by spacedout »

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
raback
Site Admin
Posts: 4812
Joined: 22 Aug 2009, 11:57
Antispam: Yes
Location: Espoo, Finland
Contact:

Re: Trying to unravel the inner workings of EOF

Post by raback »

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
spacedout
Posts: 177
Joined: 30 Mar 2020, 23:27
Antispam: Yes

Re: Trying to unravel the inner workings of EOF

Post by spacedout »

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
spacedout
Posts: 177
Joined: 30 Mar 2020, 23:27
Antispam: Yes

Re: Trying to unravel the inner workings of EOF

Post by spacedout »

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
raback
Site Admin
Posts: 4812
Joined: 22 Aug 2009, 11:57
Antispam: Yes
Location: Espoo, Finland
Contact:

Re: Trying to unravel the inner workings of EOF

Post by raback »

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

Code: Select all

LocalTemperature(1:n) = Temperature( TempPerm(CurrentElement % DGIndexes) )
-Peter
spacedout
Posts: 177
Joined: 30 Mar 2020, 23:27
Antispam: Yes

Re: Trying to unravel the inner workings of EOF

Post by spacedout »

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
raback
Site Admin
Posts: 4812
Joined: 22 Aug 2009, 11:57
Antispam: Yes
Location: Espoo, Finland
Contact:

Re: Trying to unravel the inner workings of EOF

Post by raback »

No.
spacedout
Posts: 177
Joined: 30 Mar 2020, 23:27
Antispam: Yes

Re: Trying to unravel the inner workings of EOF

Post by spacedout »

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
raback
Site Admin
Posts: 4812
Joined: 22 Aug 2009, 11:57
Antispam: Yes
Location: Espoo, Finland
Contact:

Re: Trying to unravel the inner workings of EOF

Post by raback »

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
spacedout
Posts: 177
Joined: 30 Mar 2020, 23:27
Antispam: Yes

Re: Trying to unravel the inner workings of EOF

Post by spacedout »

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
Post Reply