Irregular 3D geometries (CAD, etc.)

This category replaces the missing input manual
jesse.johns
Posts: 114
Joined: Wed Apr 20, 2011 5:19 am

Re: Irregular 3D geometries (CAD, etc.)

Post by jesse.johns » Fri Feb 05, 2016 11:26 pm

Hi,
then multiple to find the temperature in Kelvin for OpenFoam
It's not that simple to find the temperature - you have to perform a heat transfer calculation. That's where the mesh comes into play and OpenFOAM is a nice means to do your continuum mechanics coupling.
I was wondering how you can find the temperature using the "solid 1 <u> <bg>" notation.
You can get your powers (but not temperatures again for the reason stated above) for the entire "solid" volume with a detector. Or you can specify a super-lattice mesh detector to get some rough spatial power distributions as well. See section 7.1.3 in the Serpent 1 user manual.
How does Serpent change non-tetra cells to tetra cells and have you done any experiments with the volumes after conversion, especially with cylinders?
Serpent 2 also allows for Hex-cells to be used now. I don't remember which version it was implemented in, but a lot of my previous work used Exodus files built with CUBIT and with snappyHexMesh. Serpent handles these by splitting them into Tet when it processes the geometry. I have had pretty excellent results in conserving the mass and volume when using HEX. In addition, it is useful to note that Serpent doesn't care much about your mesh parameters - so skewness, cell growth, etc. can be abused so that your curvature is finely resolved and the mesh cells grow very quickly. When you iterate with the multiphysics, then you have to start caring about that again.

Ville Valtavirta
Posts: 455
Joined: Fri Sep 07, 2012 1:43 pm
Security question 1: No
Security question 2: 92

Re: Irregular 3D geometries (CAD, etc.)

Post by Ville Valtavirta » Wed Feb 10, 2016 3:02 pm

satkinson wrote:Hi Jakko,

I have used the "solid 1 <u> <bg>" notation in Serpent for my mesh based geometry. I know in the bunny example you can get the VolPower out if you are using the multiphysics approach which you can then multiple to find the temperature in Kelvin for OpenFoam. I was wondering how you can find the temperature using the "solid 1 <u> <bg>" notation. If you can use detectors what is the notation for thermal power in a detector? I will still need a T file out to place into OpenFoam for the next stage. I can swap to the multiphysics approach but it is a lot of leg work as I really appreciate the materials file option as this allows me to break up my materials easily with the celltoregion file from OpenFoam.
If you just want the cell-based power output in your geometry and you're not worried about plugging the resulting temperatures back into Serpent you can use the "solid 1" based geometry and the unstructured mesh based detector (see the detector definition in the first post of this topic http://ttuki.vtt.fi/serpent/viewtopic.php?f=24&t=2020). As Jesse noted, you'll still need to do a heat transfer calculation to get temperature distributions and that is something Serpent does not do.

Are you specifying all of your materials using one single solid? Something similar should work for the multi-physics interface in the upcoming 2.1.25. If you use the multi-physics interface, you can specify the geometry with normal Serpent cells (if you want), which should make things easier in geometries with curved surfaces.
satkinson wrote: I have tried to make my geometry using tetra cells as required by Serpent. However to obtain a realistic volume of the mesh using tetra cells within a cylinder is difficult. So far have only been able to achieve 92.5% meshing volume (and keep my cells to a reasonable level of under 2.5mil) which is having quite a negative effect on my criticality. How does Serpent change non-tetra cells to tetra cells and have you done any experiments with the volumes after conversion, especially with cylinders? I am spending a lot of time creating a mesh which is not tetra based to account for this volume loss but this might all be in vein if Serpent corrects the mesh reduces the volume again.
Your geometry does not have to consist of tetras to be used with Serpent anymore (since 2.1.21), any polyhedrons should work as long as they are made of planar faces and can be written in the OpenFOAM mesh format. However, Serpent will decompose the polyhedra into tetrahedrons for the neutron tracking. This decomposition is done in an intelligent manner for meshes consisting solely of hexahedrons since update 2.1.24, and this will be extended to meshes consisting of any combination of tetras, hexas, prisms and pyramids in 2.1.25.

The intelligent decomposition is based on J. Dompierre, P. Labbe, M. Vallet and R. Camarero, "How to Subdivide Tets, Prisms, and Hexahedra into Tetrahedra", Proceedings, 8th International Meshing Roundtable, South Lake Tahoe, CA, U.S.A., pp.195-204, October 1999.

Meshes containing other polyhedrons are split in a non-intelligent manner resulting in a larger memory consumption.

I think that both of the splitting algorithms should preserve the cell volumes as long as the cell faces are planar and the cells are convex (i.e. all space diagonals of the cell stay inside the cell https://en.wikipedia.org/wiki/Space_diagonal). If your cells are not convex, the splitting will probably lead to geometry errors, but I can't imagine your typical meshing tools producing non-convex cells in the first place.

satkinson
Posts: 23
Joined: Thu Apr 09, 2015 6:14 pm
Security question 1: No
Security question 2: 92

Re: Irregular 3D geometries (CAD, etc.)

Post by satkinson » Fri Mar 04, 2016 3:16 pm

Hi All,

Thanks for the responses. I can confirm that the splitting on hexa to tetra was very good (100.008% theoretical volume) which is much better than using tetra for cylinders.

I am looking to create T files for OpenFoam and then placing the T files back into Serpent from Openfoam, which is why I am hoping to avoid the detectors.

I am still using the irregular CAD geometries method and managed to get the full mesh to run at ~11mil elements after splitting, so quite a big job. Then tried to include the multi-physics approach but just getting the volpower for a few fuelpins. Jaakko said here: http://ttuki.vtt.fi/serpent/viewtopic.p ... m&start=20 that you need a separate interface for each material, so the fuelpins each use the same material but they are not connected by geometry so the dis1.in had several geometries from the polymesh output files from splitmeshregions. So this kicked out the error;

Fatal error in function BurnMatCompositions:

No S(a,b) flags?

Simulation aborted.

So each region needs a different materials card? Is there anyway for the whole core to have a volpower file produced? It would be great if we could use the original Polymesh files for Openfoam before the splitmesh regions for a input for multi-physics approach, unfortunately you cannot specify multiple materials for this file.

The input is simply one big solid, so I think you mentioned there might be a work around in 2.1.25 (now being used).
Cheers

User avatar
Jaakko Leppänen
Site Admin
Posts: 2354
Joined: Thu Mar 18, 2010 10:43 pm
Security question 2: 0
Location: Espoo, Finland
Contact:

Re: Irregular 3D geometries (CAD, etc.)

Post by Jaakko Leppänen » Fri Mar 04, 2016 7:25 pm

The error could result from a number of things. Try replacing the "Die" commands with "Warn" on lines 302 and 317 of burnmatcompositions.c.
- Jaakko

Ville Valtavirta
Posts: 455
Joined: Fri Sep 07, 2012 1:43 pm
Security question 1: No
Security question 2: 92

Re: Irregular 3D geometries (CAD, etc.)

Post by Ville Valtavirta » Tue Mar 15, 2016 6:45 pm

There is now (2.1.25) an unstructured mesh based interface which allows the multiple materials in one mesh. See this section in the wiki. You'll just need to produce the additional materials-file which will define the material in each of the mesh cells but that probably won't be too difficult.

If you, or anyone else, would like to also create the geometry based on the unstructured mesh the new solid 3 input card creates the geometry and brings in the temperature and density data. This will only store the geometry and multi-physics data on a single instance of the mesh and will save memory.

-Ville

satkinson
Posts: 23
Joined: Thu Apr 09, 2015 6:14 pm
Security question 1: No
Security question 2: 92

Re: Irregular 3D geometries (CAD, etc.)

Post by satkinson » Mon Mar 21, 2016 7:57 pm

Hi All,

I have input the data using method 9. I keep getting an "Index Error" in the geometry plotter. I have checked the source code and this is to do with defining colours of the materials, but these are all left undefined so I don't see why I am getting this error if you have any ideas.

So far it looks really using this new type, thanks!

Ville Valtavirta
Posts: 455
Joined: Fri Sep 07, 2012 1:43 pm
Security question 1: No
Security question 2: 92

Re: Irregular 3D geometries (CAD, etc.)

Post by Ville Valtavirta » Tue Mar 22, 2016 1:48 pm

Hi,

there is a small bug which affects the geometryplotter.c subroutine with the interface types 8 and 9 in the way you described. Luckily the fix for this problem is simple.

Change the if-branch starting from line 211 in geometryplotter.c from

Code: Select all

	  if ((ptr = (long)RDB[DATA_PTR_IFC0]) > VALID_PTR)
	    {
	      ncol = (long)(((double)COLOURS)/2.0);
	      nifc = (long)(((double)ncol - 10)/((double)ListSize(ptr));
	    }
to

Code: Select all

	  if ((ptr = (long)RDB[DATA_PTR_IFC0]) > VALID_PTR)
	    {
	      ncol = (long)(((double)COLOURS)/2.0);
	      nifc = (long)(((double)ncol - 10)/((double)ListSize(ptr)+
						 RDB[DATA_OF_N_EXTRAMAT]));
	    }
The problem is related to the way Serpent divides the color palette across different materials when interfaces are used.

-Ville

satkinson
Posts: 23
Joined: Thu Apr 09, 2015 6:14 pm
Security question 1: No
Security question 2: 92

Re: Irregular 3D geometries (CAD, etc.)

Post by satkinson » Fri Apr 01, 2016 11:54 am

Hi Ville,

The simulation ran as expected and was providing reasonable results. The Volpower results were a bit odd though. I have 1 million fuel cells, these are produced as hexa and then split during the simulation. My Volpower output only had 13000 fuel cells produced any power in them, however the criticality was indicating there was the correct amount of fuel in the simulation. So is it correct in thinking this method will only work with tetra cells? There is no algorithm for finding an average volpower for a split set of cells and returning this as the value for the whole initial input cell.

Cheers

Ville Valtavirta
Posts: 455
Joined: Fri Sep 07, 2012 1:43 pm
Security question 1: No
Security question 2: 92

Re: Irregular 3D geometries (CAD, etc.)

Post by Ville Valtavirta » Tue Apr 05, 2016 12:44 pm

Hi,

the tallying of the cell powers should work, and has been tested, also using hexas. Serpent will sum up the power from the child cells to make up the power of the initial cells. More precisely, Serpent will copy the tally bin index provided in the mapping file, from the parent cells to the child cells so that the power in each of the child cells is added to the correct tally bin. Are you providing a separate mapping-file in the interface file or are you using "-1" to set each cell to be mapped into a separate pin? Have you been able to visualize the power distribution to see where the power producing cells are located to see if they are randomly distributed throughout the geometry or in some sort of a bunch?

The only legitimate reasons for getting such results are that there is something wrong with the tally-bin mapping or there are no interactions sampled in the rest of the fuel cells during the neutron transport, which does sound strange if you are running a reasonable number of neutrons.

-Ville

Andy_Turner
Posts: 18
Joined: Tue Jan 12, 2016 11:38 am
Security question 1: No
Security question 2: 92

Re: Irregular 3D geometries (CAD, etc.)

Post by Andy_Turner » Thu May 05, 2016 5:58 pm

Jaakko Leppänen wrote:Do you mean CAD or mesh-based geometry?

With mesh-based geometries you can use the "dumsh" option with detectors:

Code: Select all

det <name>
dumsh <uni> <N>
<c1> <b1>
<c2> <b2>
...
<cN> <bN>
where <uni> is the mesh universe. You can list <N> mesh cells (<c1>, <c2>, ... ) which are mapped into <N> detector bins (<b1>, <b2>, ...). You can have a single bin for each cell, or you can combine multiple cells in one bin. The list doesn't have to cover all mesh cells in the geometry, but the detector is scored only in the listed cells.

In CAD-based geometries you assign a cell name with one or multiple solids. These cells can be used with detectors as well.
I am creating a CAD/STL based geometry, and Serpent2.1.26 refuses to let me use the serpent cell IDs I assign in any detectors (dc) or in the source (sc). Says cell N in detector xxx not defined.
Does one have to do anything special / undocumented to make it work?
- Andy Turner, CCFE

Post Reply