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
Newbie asks for advice, FreeCAD, OpenCASCADE, pythonocc
Forum rules
Be nice to others! Read the FreeCAD code of conduct!
Be nice to others! Read the FreeCAD code of conduct!
Re: Newbie asks for advice, FreeCAD, OpenCASCADE, pythonocc
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 2manifolds. 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 supercomputers
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 datastructure) 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 FEMMeshes, or Voxel data in CAM simulation or others. Which leads normally to a translator in some kind....
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 datastructure) 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 FEMMeshes, or Voxel data in CAM simulation or others. Which leads normally to a translator in some kind....
Stop whining  start coding!
Re: Newbie asks for advice, FreeCAD, OpenCASCADE, pythonocc
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.jriegel wrote: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 2manifolds. 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 supercomputers
Using triangular meshes can do the job also and are easier to optimize. You introduce some errors (discretization) which has to be managed.
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.
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.What we not can do (neiter OCC nor our triangular mesh datastructure) 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....
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).
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 (FEMtype meshes) is that in many application, the surfacetovolume 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 FEMmeshes; you need an excessive number of excessively small meshes to maintain accuracy.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 FEMMeshes, or Voxel data in CAM simulation or others. Which leads normally to a translator in some kind....
OK. I am learning things these days. Very interesting
 tanderson69
 Veteran
 Posts: 1619
 Joined: Thu Feb 18, 2010 1:07 am
Re: Newbie asks for advice, FreeCAD, OpenCASCADE, pythonocc
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?WvR wrote: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.What we not can do (neiter OCC nor our triangular mesh datastructure) 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....
modata.pdf
A composite solid is a set of solids
connected by their faces. It expands the
notions of WIRE and SHELL to solids.
Re: Newbie asks for advice, FreeCAD, OpenCASCADE, pythonocc
No, not really, its just a closed shell > solid...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?
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 piecewise 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...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).
What one can do anyway is to build a complex setup and then subtract this setup from a huge box, which generate a solid(s) which represent the rest of space (air)...
I have to say I learned also a lot from this thread! Very interesting indeed!OK. I am learning things these days. Very interesting
Stop whining  start coding!
 tanderson69
 Veteran
 Posts: 1619
 Joined: Thu Feb 18, 2010 1:07 am
Re: Newbie asks for advice, FreeCAD, OpenCASCADE, pythonocc
You do realize I said TopAbs_COMPSOLID and NOT TopAbs_COMPOUND? There is more going on than just a close shell.jriegel wrote:No, not really, its just a closed shell > solid...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?
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.
 Attachments

 CompoundSolid.fcstd
 (89.67 KiB) Downloaded 105 times
Re: Newbie asks for advice, FreeCAD, OpenCASCADE, pythonocc
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.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 piecewise 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 setup and then subtract this setup from a huge box, which generate a solid(s) which represent the rest of space (air)...
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.