Xraytrace documentation

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
===== Sample geometry =====

As mentioned in the [[computational_domain|computational domain]] section, everything is computed on rectangular domain consisting of rectangular voxels. Ways of loading medium data from different input file types are described there as well.

As we are working with voxel data, first aspect to note that there is a staircasing effect in the data, present nearly for any more complicated geometries. This means that e.g. a half-spehere looks like this:

{{ :voxels.png?200 |}}

There are different algorithms implemented to reduce the effect of staircasing, e.g. gradient based normals evaluation for Fresnel equations, however it is important to have in mind always this intrinsic nature of a voxel based mesh. 


Here we describe more in detail how to prepare the sample geometry input files. If **VTK file input** is used, the files are typically prepared using some script, directly writing the regular unstructured mesh VTK file (ASCII format). This is the simplest 3D input format possible. Every voxel is addressed by an integer, which should correspond to entries in the materials file. Material with index 0 is always vacuum, the others can be defined freely in the materials file. The total span of integer values in the VTK file should match (or be smaller) than the number material file entries.

In case of **vector file input**, the information is provided in a form of simple geometric entities (e.g. a sphere) that are placed to the computational domain and interpreted by the software. In general, object entries are composed from the object type (integer), positions and sizes (doubles). The last entry is always the material index, which again should match the materials file. Object type numbers and related syntax is the same like for the [[http://gsvit.net|Gsvit]] software, so some of the conventions might look unusual from Xraytrace perspective and are used only for compatibility purposes. The following rules are used in the data interpretation:
  * When we specify the vector file input, we also give the voxel size of the rectangular box on which the vector inputs will be interpreted. It is not necessary for the objects to be fully within this rectangular box, however only the data that are inside box are used for the computation. 
  * The objects are interpreted in the order as they are listed in the file. In the overlapping areas the information is replaced while adding next object, this can be used e.g. to create a hole within an object.
  * All object positions and sizes are given in voxel coordinates. They don't need to be entered as integers (which is important e.g. for a sphere radius). However, they are evaluated on a voxel mesh, so using a vector input does not prevent to the staircasing effect.

The following examples of the vector file input lines show the objects that can be entered:

A **sphere** (object type = 4) is set by its center coordinates followed by radius and material index as shown in the following example:
<code>
4 100 100 100 20 2
</code>
This puts a sphere to the voxel position of 100,100,100, with radius of 20 voxels and filled by material index equal to 2. 

A **rectangular box** (object type = 8) is set by its bottom-left-front and top-right-back voxel positions followed by the material index, like here:
<code>
8 0 0 0 400 400 100 2
</code>
If our computational domain is a box of 400x400x200 voxels, this fills half of it (e.g. providing a substrate for further calculations), with material of index equal to 2.

A **cylinder** (object type = 7) is defined by position of the front circle center, back circle center, cylinder radius and material index, like here:
<code>
7 200 200 100 200 200 120 150 3
</code>
This creates a cylinder placed at xy position of 200, 200, with axis oriented in z direction, of length of 20 voxels and radius of 150 voxels (so it is more like a disc).

A **cone** (object type = 107) is defined by position of the base circle center, apex center, base cylinder radius and material index, like here:
<code>
107 200 200 100 200 200 150 30 3
</code>
This creates a cone placed at xy position of 200, 200, with height of 50 voxels and base radius of 30 voxels filled by material of index equal to 3.

A **cut cone** (object type = 108) is defined by position of the front circle center, back circle center, both cylinder radii and material index, like here:
<code>
108 200 200 100 200 200 150 30 15 3
</code>
This creates a truncated cone placed at xy position of 200, 200, with height of 50 voxels and base radius of 30 voxels and top radius of 15 voxels, filled by material of index equal to 3.


As an example of multiple entries like the above ones we show here a Paraview visualisation of the mat.vtk file that is generated after you load the vector geometry. Using the following input file:
<code>
4 50 50 50 20 2
7 150 50 50 150 50 80 20 2
107 50 150 90 50 150 50 20 2
108 150 150 80 150 150 50 15 35 2
8 0 0 0 200 200 50 3
</code>

we got the following output. Note that the sphere is immersed into the substrate, so it looks as only a halfsphere.

{{ :objects.png?400 |}}


As the voxel based mesh features the staircasing effect, we need to handle the surface normal calculation carefully, while evaluating interaction of the ray with the object. Use of some particular method is chosen in the main parameter file, using e.g. this command

<code>
INTERFACE_METHOD
3
</code>

which sets the crudest method significantly affected by staircasing.

There are different surface normal evaluation methods implemented: if we use 0 as the above command parameter, simple weighting of the pixel neighbourhood is used. Regime 1 means something more advanced, however again based on weighting of the amount of material around the pixel where we do the evaluation. Regime 2 is most resistant to staircasing, being based on pre-calculation of local neighbourhood gradient and then using this information as shown in the figure below. Finally, regime 3 means only local evaluation, searching for adjacent voxels and should be used only for rectangular objects.

If the gradient based control method is used, it can be controlled further by local averaging area selection, using e.g. this directive:
<code>
AVERAGE
3
</code>

The provided value is typically in range of 2-5, the higher value the smoother the object boundaries are. However, too much of smoothing can also remove some fine details. Note that gradient based method is precomputing the data at the calculation start, this can affect the computation time.

{{ :normals.png?400 |}}
Xraytrace documentation

User Tools

Site Tools

Page Tools
