Question regarding input

[Ferraro, Diego Ernesto (INR)]

Dear milonguers;

  I’m struggled with some milonga problem and I cannot figure out what I’m doing wrong. I basically try to model a 3x3 3-D minicore, water reflected, with a central CR.

  I’ve simplified the geometry to be able to run with structured meshes (basically everything is a extruded geometry) and avoided any kind of scripting in the .geo geometry definition to avoid problems.

  I see the geometry and looks Ok. When I mesh it, no problem arise (I use milonga 0.5.44 and gmsh 3.0.6). But, when I run it, I get two problems:

-          If I run it using finite elements, everything runs Ok, the Keff looks ok (600 pcm, should be critical but it’s a good start), but when I check the fluxes I see some strange behavior (even negative)

-          If I try to run using finite volumes, I get an error related to one mesh:

error: mesh inconsistency, element 24001 has at least one more neighbor than faces (6)

-          When I check that element in gmsh I don’t see any problem at all.

-          I have already tested different element orders and meshing algorithms, without any success.

So I’m missing something? I’m attaching the inputs just in case.

Thanks in advance,

Diego

 

 

[César Pablo Camusso]

Dear Diego,

I think that this error:

If I try to run using finite volumes, I get an error related to one mesh:

error: mesh inconsistency, element 24001 has at least one more neighbor than faces (6)

is because you are using 2 order elements in finite volumes. If I do not remember badly finite volumes only uses 1 order elements.

However, you have intersections in surfaces. For example volumes 38, 39, 40, 41, 42, 43, 44 have surfaces 1047, 1069, 1091, 1113, 1135, 1157, 1179; all these surfaces intersect the surface 725 of the volume 23.

I think that it also hapens in the four sides of volumes 38, 39, 40, 41, 42, 43, 44.

Perhaps the boolean operators can help you.

--
You received this message because you are subscribed to the Google Groups "wasora" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wasora+un...@seamplex.com.
To post to this group, send email to was...@seamplex.com.
Visit this group at https://groups.google.com/a/seamplex.com/group/wasora/.
To view this discussion on the web visit https://groups.google.com/a/seamplex.com/d/msgid/wasora/7fed28f7ef9e43a68d33a7d35b4b534b%40kit-msx-25.kit.edu.
For more options, visit https://groups.google.com/a/seamplex.com/d/optout.

[Ferraro, Diego Ernesto (INR)]

Thanks pablo!

I suppose then that I should go a couple of steps back because clearly I’m doing the things wrong in gmsh. I just build the model using extrusions, but obviously that’s not the path.

Thanks!

Diego

To view this discussion on the web visit https://groups.google.com/a/seamplex.com/d/msgid/wasora/1072967926.428446.1536238335657%40mail.yahoo.com.

[jeremy theler]

ok, let us make a "bisection" algorithm

first, one of wasora's design basis motto is "simple problems ought to have simple inputs" so I made a NxN core with the attached geo file and solved it with milonga with the attached mil file. You do not get any negative fluxes:

gtheler@hera:~/run/milonga/diego$ milonga NxN.mil | sort -gk5 | head
# x     y       z       phi1    phi2
4.03331 1.2116  1.12441 2.23133e+13     1.09766e+12
1.2116  4.03331 1.12441 2.25762e+13     1.11353e+12
58.7884 3.9764  48.92   2.34861e+13     1.15061e+12
56.0236 1.2116  48.92   2.36297e+13     1.15229e+12
56.0236 58.7884 48.92   2.37096e+13     1.16156e+12
58.7884 56.0236 48.92   2.39478e+13     1.1674e+12
1.2116  3.9764  48.92   2.41968e+13     1.18523e+12
3.9764  1.2116  48.92   2.43145e+13     1.1856e+12
1.2116  55.9667 1.12441 2.43815e+13     1.20515e+12
gtheler@hera:~/run/milonga/diego$ milonga NxN.mil | sort -gk6 | head  
10.0002 1.2372  48.5566 4.67893e+13     2.20707e+12
10.0002 18.7628 48.5566 4.34507e+14     3.31561e+13
10.0002 21.2372 48.5566 4.53735e+14     3.4815e+13
10.0002 41.2372 1.44338 4.09666e+14     3.1017e+13
10.0004 21.4747 1.33927 3.52659e+14     2.27185e+13
10.0004 41.476  48.6607 3.23607e+14     2.08153e+13
10.0006 1.2372  1.33927 4.72118e+13     2.18944e+12
10.0006 18.7628 1.33927 3.90665e+14     2.89547e+13
10.0006 38.7628 48.6607 4.116e+14       3.08294e+13
10.0006 58.7628 1.33927 4.75272e+13     2.21796e+12
gtheler@hera:~/run/milonga/diego$

let us assume this is point a (the simple solution that works) and your 3x3 case is point b (the complex problem that does not work). What would 0.5*(a+b) be?

BTW, I used a .geo file because point "a" is very simple. For more complex geometries, I would either

a. use a CAD tool like FreeCAD to model the reactor geometry, export to BREP and import it back in Gmsh

b. use Gmsh's python API to do more complex loops, conditionals and math

[jeremy theler]

On Thu, 2018-09-06 at 12:52 +0000, 'César Pablo Camusso' via wasora
wrote:

> Dear Diego,
> I think that this error:
> If I try to run using finite volumes, I get an error related to one
> mesh:
> error: mesh inconsistency, element 24001 has at least one more
> neighbor than faces (6)
> is because you are using 2 order elements in finite volumes. If I do
> not remember badly finite volumes only uses 1 order elements.

This (i.e. using 2nd-order elements with FVM) should be detected as an
error by milonga. I wonder why it didn't.

BTW, why is it that you use 2nd-order elements? The only reason they
are there is because they should be used in Fino for mechanical
problems. I do not see any gain in using them for neutron transport.

[jeremy theler]

On Thu, 2018-09-06 at 13:36 +0000, Ferraro, Diego Ernesto (INR) wrote:
> Thanks pablo!
> I suppose then that I should go a couple of steps back because
> clearly I’m doing the things wrong in gmsh. I just build the model
> using extrusions, but obviously that’s not the path.

that is because you wanted structured grids because almost any other
code out there uses structured grids so all benchmarks out there use
strucutred grids, and so on.

in any case, I would create rectangles using opencascade's primivitives
and the extrude those surfaces instead of using the bottom-up approach
of points, lines, surfaces, volumes, etc.

[jeremy theler]

BTW, if you still want structured grids (I would not recommend it),
maybe it is better to use wasora's internal strucutred meshes

take a look at

https://bitbucket.org/seamplex/milonga/src/master/examples/2dpwr_structured.mil

[jeremy theler]

Find attached a reflected version (the same reflector in the radial and
axial directions though). For sure you can work out the details to
convert this into the original benchmark.

Even though there are negative fluxes, I think they are due to
numerical issues (two orders of magnitude smaller than the positive
flux). Try to use a finer mesh and they should be gone (I am using a
laptop to run milonga so I might run out of memory).

[Ferraro, Diego Ernesto (INR)]

Thank you guys for all the answers!
I'll check that and tell you how it goes. Obviously I have to go in-depth with gmsh (I clearly misunderstood the geometry building scheme).
Thanks,
Diego
Ps. BTW, it could be a nice option for milonga to have a "mesh consistency" check option to check faces, mass and volumes, that are usually messed up (by users like me :) ), something like
MESH FILE_PATH NxN-reflected.msh DIMENSIONS 3 OPTIONS check_faces print_volumes, ...
I understand that milonga makes some of this checks afterwards before calculating, but could be good options when you are developing your model to have more info.

-----Original Message-----
From: jeremy theler <jer...@seamplex.com>
Sent: Freitag, 7. September 2018 00:18
To: wasora <was...@seamplex.com>
Subject: Re: [wasora] Question regarding input

To view this discussion on the web visit https://groups.google.com/a/seamplex.com/d/msgid/wasora/8b52df86074bd854604ee97109914836f65a9c84.camel%40seamplex.com.

[jeremy theler]

can you ellaborate what you would like to have?
I know buggy meshes are hard to debug, but we know something is wrong
when we have to use it and we cannot (for example, more neighbors than
faces) so if we have to "check" and then "run" we would be doubling the
code.

the faces are checked in FVM when evaluating the spatial operators
what do you mean by "print_volumes"?