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.
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.