Newbie asks for advice, FreeCAD, OpenCASCADE, pythonocc

[ickby]

Interesting discussion. Just a small remark: open cascade is not thread safe in general. Actually they just started thinking about and working on multithreading. Therefore making the algorithms work on multiple cores may need some hard work on the occ classes. Or copying the geometry for every thread of course

Have a look here for a few details: http://opencascade.blogspot.com/2008/12 ... ow_06.html

[jriegel]

We had already discussions with people from CERN which do similar kind of simulation (I think for one of the detectors). Modeling your problem with cubes and cones is obvious from a algorithmic standpoint. Unfortunately its nowadays not practical anymore. You will get a lot of the 3D data nowadays as BREP (from all the CAD systems via a.g. STEP/IGES) or as a triangular mesh (from nearly all). All of the data are hull representation which are strictly 2-manifolds. Detecting intersection and inside/outside is very easy and accurate (perfect) on BREP but also very slow! If you go for millions and billions you will need bigger super-computers
Using triangular meshes can do the job also and are easier to optimize. You introduce some errors (discretization) which has to be managed.

What we not can do (neiter OCC nor our triangular mesh data-structure) is this kind of 'cell' approach, where you describe only parting surfaces! Our data model are always a closed surface around a finite solid volume of one material or property. That mean also in BREP your parting faces are always two faces in touch. Ant they are normally don't know of each other....

But anyway is the standard approach in such kind of simulation to use BREP and the CAD system to model and plan. But the simulation is done in a specialized data structure. Like FEM-Meshes, or Voxel data in CAM simulation or others. Which leads normally to a translator in some kind....

[WvR]

We had already discussions with people from CERN which do similar kind of simulation (I think for one of the detectors). Modeling your problem with cubes and cones is obvious from a algorithmic standpoint. Unfortunately its nowadays not practical anymore. You will get a lot of the 3D data nowadays as BREP (from all the CAD systems via a.g. STEP/IGES) or as a triangular mesh (from nearly all). All of the data are hull representation which are strictly 2-manifolds. Detecting intersection and inside/outside is very easy and accurate (perfect) on BREP but also very slow! If you go for millions and billions you will need bigger super-computers
Using triangular meshes can do the job also and are easier to optimize. You introduce some errors (discretization) which has to be managed.

The people at CERN have an even more complicated problem, namely that particles do not fly in straight lines, but the trajectory is determined by the interaction with magnetic and electric fields. I hate charged particle transport. And then the particles also decay while they are flying, so it is a very interesting task from the computational point of view.

There are basically two ways to simulate particle transport: first, there is the Monte Carlo method. This works always, whether the particles have a charge or not. The idea is simple: assume you know where a particle is in space, where it is going (direction) and the particle energy. Then, depending on the material in which the particle is, you decide how far the particle will travel before a collision occurs; at the point of collision, you determine what kind of reaction happens, and you follow the particle along the new path, and so on and so forth, until at some point the particle disappears. In this method, the tracking of the particle happens while the particle is moving through space. Thus, it is vital that the determination of surface crossings is efficient and robust.

If you are dealing with uncharged particles, the problem can be simplified, because you know that the particle fly along straight lines (if we neglect gravity, which is usually no problem unless when dealing with applications involving cosmology and astrophysics). Thus, you can split the calculation in two steps: the first step is to determine the intersections of all the straight lines, and second you determine how many particles are flying along each line. This is known as the Method of Characteristics (MOC) because the "solution lines" are "characteristic solutions" of the differential equation that describes the transport problem.

For places as CERN, dealing with charged particles, the characteristic solutions are hopelessly comlex and Monte Carlo is much easier to implement. However, I am focusing on the MOC because the tracking of the uncharged particles is independent of the solution method. In other words, you can use whatever tracking module relevant to your problem, and if your data exchange is OK, you can use the same neutron transport solver, independent of the description of the geometry: all you need is the length of each of the line segments. Also, in many cases, you need to make many solutions based on one geometry. For example, in a nuclear reactor one may put fresh fuel assemblies in the core. However, given that the fuel assemblies are usually all the same, the geometry does not change, even if the materials are different. Thus, the tracking set can be recycled. In Monte Carlo, each calculation is statistically independent, and thus you need to redo all the work: tracking and solution.

There is one major problem with Monte Carlo, and that is that you can never be sure that there have been particles in all parts of the entire problem domain. Thus, the solution may give a false convergence. With MOC, the user controls where the solution lines are placed, and you can have an optimal solution.

What we not can do (neiter OCC nor our triangular mesh data-structure) is this kind of 'cell' approach, where you describe only parting surfaces! Our data model are always a closed surface around a finite solid volume of one material or property. That mean also in BREP your parting faces are always two faces in touch. Ant they are normally don't know of each other....

This is a very interesting comment. In traditional Monte Carlo codes, depending on the input format, there may also be "gaps" between the cells. In practice, that usually indicates an error in the geometric model (user error) but in some cases it can't be avoided. Particles that go into such undefined locations are said to be "lost". Monte Carlo codes usually abort the calculation if too many particles are lost.

Is there any guarantee about the "distance" between the faces of two connected bodies? For example, in OCC there seem to be some basic settings for precision, so is there any guarantee that the two faces are within a certain precision of each other?

In the tracking algorithm, one has to make a list: for each "cell", one needs a list of "next entered cells". In the beginning, these lists are empty, and tracking may be slow because many geometric entities are tested, but as the tracking continues, the list of "entered cells" steadily grows until at some point you have a near 100% chance that the next cell will be in the list. The problem is then how to decide the next cell. If you know an "outgoing" intersection, you have to calculate the distance to all "next ingoing" intersections, and take the one that is nearest the present point (if there is a guaranteed precision between the outgoing and the incoming surface, the next point should be within that precision, which would make the decision more robust).

But anyway is the standard approach in such kind of simulation to use BREP and the CAD system to model and plan. But the simulation is done in a specialized data structure. Like FEM-Meshes, or Voxel data in CAM simulation or others. Which leads normally to a translator in some kind....

In neutron transport for nuclear reactors, but also for other applications such as cancer treatment, all possible permutations have been tried. The biggest problem with triangulations (FEM-type meshes) is that in many application, the surface-to-volume ratio needs to be preserved rather accurately, which is not always possible with triangulations. Also, in nuclear reactor applications there are many cases where very small volumes occur, which are very demanding to represent with FEM-meshes; you need an excessive number of excessively small meshes to maintain accuracy.

OK. I am learning things these days. Very interesting

[tanderson69]

What we not can do (neiter OCC nor our triangular mesh data-structure) is this kind of 'cell' approach, where you describe only parting surfaces! Our data model are always a closed surface around a finite solid volume of one material or property. That mean also in BREP your parting faces are always two faces in touch. Ant they are normally don't know of each other....

This is a very interesting comment. In traditional Monte Carlo codes, depending on the input format, there may also be "gaps" between the cells. In practice, that usually indicates an error in the geometric model (user error) but in some cases it can't be avoided. Particles that go into such undefined locations are said to be "lost". Monte Carlo codes usually abort the calculation if too many particles are lost.

Sorry to butt in. Freecad doesn't work with this "cell" data structure but I believe that OCC itself does support it through the type TopAbs_COMPSOLID?

modata.pdf

A composite solid is a set of solids
connected by their faces. It expands the
notions of WIRE and SHELL to solids.

[jriegel]

Sorry to butt in. Freecad doesn't work with this "cell" data structure but I believe that OCC itself does support it through the type TopAbs_COMPSOLID?

No, not really, its just a closed shell -> solid...

If you know an "outgoing" intersection, you have to calculate the distance to all "next ingoing" intersections, and take the one that is nearest the present point (if there is a guaranteed precision between the outgoing and the incoming surface, the next point should be within that precision, which would make the decision more robust).

The accuracy depends on the modeler you CAD data coming from. Nowadays around 0.0001 mm. If you design two solids touching, they are normally touching very accurate. The face of the one and the other are piece-wise coincident. But you will have the same problem as e.g. the CFD guys. Normally CAD models consist of solids arranged in 'Air'. In most modelers its a bit tricky to model a assemblies which is completely "filled". The tools are normally geared toward different things...

What one can do anyway is to build a complex set-up and then subtract this set-up from a huge box, which generate a solid(s) which represent the rest of space (air)...

OK. I am learning things these days. Very interesting

I have to say I learned also a lot from this thread! Very interesting indeed!

[tanderson69]

Sorry to butt in. Freecad doesn't work with this "cell" data structure but I believe that OCC itself does support it through the type TopAbs_COMPSOLID?

No, not really, its just a closed shell -> solid...

You do realize I said TopAbs_COMPSOLID and NOT TopAbs_COMPOUND? There is more going on than just a close shell.

Here is a procedure to use DRAWEXE to build a TopAbs_COMPSOLID:http://www.opencascade.org/org/forum/th ... 1/?forum=3

output of DRAWEXE nbshapes:

Code: Select all

Number of shapes in mycomp
 VERTEX    : 8
 EDGE      : 16
 WIRE      : 10
 FACE      : 10
 SHELL     : 2
 SOLID     : 2
 COMPSOLID : 1
 COMPOUND  : 0
 SHAPE     : 49

I have attached a file showing the brep from above procedure. It also contains a hierarchy of the sub shapes.

[WvR]

The accuracy depends on the modeler you CAD data coming from. Nowadays around 0.0001 mm. If you design two solids touching, they are normally touching very accurate. The face of the one and the other are piece-wise coincident. But you will have the same problem as e.g. the CFD guys. Normally CAD models consist of solids arranged in 'Air'. In most modelers its a bit tricky to model a assemblies which is completely "filled". The tools are normally geared toward different things...

What one can do anyway is to build a complex set-up and then subtract this set-up from a huge box, which generate a solid(s) which represent the rest of space (air)...

Indeed, the question is how to treat the fact that sometimes there is an "undefined" space between surfaces. In my opinion, these undefined spaces should be left undefined. Otherwise, there may be a genuine error in the geometry, but it will be accepted if "undefined" space is substituted automatically. In most codes for nuclear engineering, quality control is important, and it is generally unacceptable if a code will give a seemingly correct result from an erroneous input. Most codes are designed to be paranoid, i.e. they are more likely to (mistakenly) reject a correct input, than mistakenly accept an erroneous input.

In CFD the stituation is different because in general there you are dealing with a relatively sparse geometry, i.e. objects placed in a fluid. In most particle tracking codes all space needs to be defined. But this is indeed something I will start investigating a bit more closely.

And indeed, in all these codes you need to find out whether or not a particle has left the domain (or, in the case of MOC, you need to know where to start the tracking lines, because the start point should be on the exact boundary of the domain). In most codes, indeed the user defines a sphere around the entire problem domain, with the explicit setting that particle tracking can be stopped once the particle crosses the sphere.