This documentation describes mozi-1.0.3.
Knowing my programming skills I do not think I will publish anything even at beta level.
mozi is small GL based program intended to visualize simulations of granular material. It has been optimized to view sequences of images of different particles and their physical properties which are stored in a specially crafted file. It can represent velocities, forces, etc. by arrows or color code and has the ability to show only a subset of the particles described by totally free constraints. Finally, it may create an mpeg movie in the background.
Important remark: This code was written by a physicist who is not in any mean a good programmer. I spent 10 years in writing small, few hundred line codes for simulations that are entirely free from any on run checking. Programs were to be efficient and not user friendly. As I was the only user of them they were not user safe at all and of course they contained no documentation. So bad input and miscellaneous usage is very badly checked and may result in an unwanted behavior. This is also true for this program however I made my best to make it more robust. Meanwhile use it really at your own risk! I write this documentation because people started using this program and found it useful. Please, send remarks and suggestions to me.
For copyright see the GNU licence.
mozi is the Hungarian word for movie.
usage: mozi [-h] [-B] [-c contraint] [-d] [-f ttf font] [-b max bodies] [-r] [-s] [-t] [-w] [-g clength] [moviefile]
mozi comes with a file fileformat.txt which contains the up to date information of file format. Being input for mozi is not the sole purpose of datafiles described here they must be also eligible for easy access of properties of particles. getcol4.c is the program the extracts these information. Any suggestion for new fileformat should come in this spirit.
This manual describes in detail different supported fileformats. You may skip to the currently supported one.
A line in the input file is considered as one snapshot except for the header. In text file it is indeed one line. In binary format it is terminated by the BT_EOL object.
Some fileformats are text, others are binary. Currently no architecture independent binary (XDR) is supported for binary format. A stupid check is performed although this must be changed later on. All data files start with a small text header that is described below.
Most fileformat start with the line
#type X
where X is a number that specifies the version of the input file. In binary formats the above line is extended as follows:
#type X I D L
where X is the same as before, I: sizeof(int), D sizeof(double), L linelength if that is fixed and known. if L==-1 than at start mozi sweeps through the whole file and determines each line length. It is very important if fixed linelength is used moziassumes that each line contains the same set of objects with the same parameters. If linelength varies the first line must contain all objects even if in the first timestep their number is zero. In this case insert it with number zero. Later unused object may be left out but in certain conditions it may lead to unwanted behavior. If the objects are different this does not happen.
Note, that speed can be increased by using binary formats and especially fixed linelength.
All header lines start with #. In text formats data starts after the last header option. In binary file a line with a single hash marks the end of the header and what comes after the new line character is considered as data.
This parameter is an integer. Each object has a certain number of compulsory parameter. Generally it is its size. In currently supported fileformat (Type 4 and Type 6) these parameters appear at the beginning of each object. The symbols (e.g. rx) are used in constraints.
BT_EOL 0 (00000)
BT_Wall 1 (00001) dx(double), dy(double)
BT_Ball 2 (00010) dx(double)
BT_Cylinder 3 (00011) dx(double), dz(double)
BT_Disk 4 (00004) dx(double)
BT_BallCC 5 (00101) dx(double), dy(int)
BT_Force 6 (00110) dx(double), dz(double), i1(int), i2(int)
BT_STBall 7 (00111) dx(double)
BT_DTEdge 8 (01000) dx(double), dz(double), i1(int), i2(int)
BT_DGBall 9 (01001) dx(double)
Each object may have different parameters. Only position and orientation is used during default plot. Others can be accessed in constraints. Both orientation and position can be omitted. Default orientation is along the y axes, default position is origin.
Currently 4 different textures are supported by mozi. Texture field is a byte that is split into two parts. The lower 4 bits (0-15) determine the texture number or the color scheme (the latter is still in the to do list, sorry.). If bit 5 is set than no texture is used the object is colored. If bit 6 is set the object is transparent.
This field can be totally reset in mozi.
mozi allows for setting up stationary objects in the header that does not move and always there through the whole run. This may save space in certain conditions. In the beginning this was important but now I think this should become depreciated.
After the type element any number of the following object may follow:
#object type(byte) tex(byte) num(int) {Pos Orient}*num
Text format
This fileformat is depreciated but so simple that it will be kept.
This format plots only balls except for #object.
Line format:
time(int) num(int) {Pos Orient}^num
Text format
This fileformat is depreciated.
Line format:
time(int) type(int) tex(int) num(int) {Pos Rot dx [dy] [dz]}^num type(int) ....
This format knows only BT_Ball, BT_Wall, BT_Cylinder, BT_BallCC. There is no BT_EOL as it reads until text file end of line.
Note: the size of the object is at the end of the data record while in currently supported formats is at the beginning.
Binary format of type 1
Not supported any more. Some code is still there but conflicts with type 4. Should be removed.
Text format of type 4
Never was supported.
Binary format
The currently supported format. Use this!
This is described more in detail as this is what you supposed to use:
Header
#type 4 I D L #object ... #
where I: sizeof(int), D sizeof(double), L linelength if that is fixed and known. if L==-1 than at start mozi sweeps through the whole file and determines each line length. In most cases you have
#type 4 4 8 -1
The data starts after the line with only a single '#' and a new line.
Each line is a snapshot and displayed at once. A line is constructed as follows:
time(double) {object} {object} ... BT_EOL
Time is a double variable, that will be accessible in constraints. Then come different objects as described below and at the end BT_EOL which is just a 0(int).
An object is a given number of particles with the same geometric shape but with different parameters. It is constructed as follows:
type(int) tex(byte) num(int) {parameters}^num
The lower 5 bit of the type was defined above. The upper bits show which parameters are present as described above. tex is the texture as described above. num is the number of bodies. The parameter set is expected to be repeated num times.
Here a simple example is described. We have one stationary object, a cylinder, In the first snapshot a wall with only position and orientation, in the second timestep a ball appears.
On 32 bit, Intell or AMD processor the input file contains the following:
First three lines are text:
#type 4 4 8 -1 #object 3 99 1 0.0 0.0 0.0 0.0 0.0 1.0 0.0 0.003 0.009 #
Binary part: Format typecharacter and value. Type: i=int, d=double, c=char/byte. eg double 0.003 => d0.003.
First `line', note that Ball is represented here with 0 number to inform mozi about its presence, 354=2+32+64+256=BT_Ball+Pos+Orient+Velo.
time type(Wall) tex(yes:0) num(1) size_x size_y d0 i1 c0 i1 d0.006 d0.006 type(Ball) tex(yes:1) num(0) i354 c1 i0 type(EOL) i0
Second and third line line (no eol! just continue)
time type(Wall) tex(yes:0) num(1) dx dy d1 i1 c0 i1 d0.006 d0.006 type(Ball) tex(yes:1) num(1) dx x y z rx ry rz phi vx vy vz i354 c1 i1 d0.002 d0.0005 d0.001 d0.0 d1.0 d0.0 d0.0 d0.78 d0.0 d0.0007 d0.0005 type(EOL) i0 time type(Wall) tex(yes:0) num(1) dx dy d2 i1 c0 i1 d0.006 d0.006 type(Ball) tex(yes:1) num(1) dx x y z rx ry rz phi vx vy vz i354 c1 i1 d0.002 d0.0005 d0.001 d0.001 d1.0 d0.0 d0.0 d0.78 d0.0005 d0.0007 d0.0005 type(EOL) i0
The resulting file can be downloaded from here.
Essentially the same as Type 4 but also color of a body can be specified. It is untested yet but soon will become the official format.
The only difference is that texture (tex) is an integer that stores the following information:
mozi currently supports XYZ files. This support is experimental and its future lies upon the development of the constraints. In this state it is not very useful compared to other viewers developed for the chemist community. The only relevance of this is the movie creation which is a weak point of freely available chemical softwares. Please, let me know whether this support might be useful if bonds and other properties can be calculated via constraints or free chemical viewers do a much better job. In this case the different snapshots are separate XYZ data connected to one file.
The menu system of mozi is the following:
*Never destroy popup windows. In most cases it makes mozi crash. Use cancel or hide window button to get rid of unwanted windows.
The GL window is used to move and rotate the object.
Keys are case sensitive. For orientation and position control see also Set/Key step menu option.
Control window is divided into frames according to function. Except for animation frame all of them can be switched off by pressing the 'Off' button. In order to show them again use View menu.
In this section the text processing algorithm is described. You may well guessed that the change from clicking to text editing was done by a linux user but it has many advanteges. First of all it can be saved and reloaded. Easy to change, suspend and much more flexible. The price you pay is at the beginning it sounds too complicated and one needs some practice. I try to present some examples at the end of this section that may help.
This chapter is organized as follows:
Commands sectin requires some knowledge about the expressions. Follow links if unclear.
The text box for contraints has only the very basic GTK editing features. Line breaking does not play a role and as will be described later it is easy to add comments to the commads. Organize it as you like.
There is an undo/redo system in mozi but that only works among stages that were successfully updated.
Copy and paste works from other windows but inside the same box does not. During editing a lot of on the fly staff is performed that prevents copy-paste into itself. Be carefull because it can destroy your text. Copy to an other place and paste back. Or cut and then paste multiple times.
Save anything that seems useful and reuse it.
There are 12 keywords or commands that mozi understands. They are listed above the text field. When entered they appear in bold face fonts. They have a number of parameters which must be written between a pair of brackets '[' ']'. The parameters are seperated by semicolons ';'. Generally, parameters are optional. The different commands should be listed one after an other. In some cases (described below order does metter). Any text outside the pair of brackets are ignored and can be used as comments except for the star '*' following the closing bracket which means to switch out the preceeding command.
Example:
Cut[0;0.001] Size[dx/2;1;3]* Kukucs Show[dx>0.01;3]
The second 'Size' command is switched off. 'Kukucs' is text outside brackets considered as a remark and ignored.
While you enter the text a small help about the current parameter is shown above the text fild on the right hand side of the window. When you press update and there is an error that will be printed at the same place but with underlined text. Be careful! After the description in paratheses the nature of the parameter is indicated, (v) is vector, (s) is scalar. It is general for constraints that there is no error message for mixing up vectors and scalars. You mast be keep track of them the general scheme is that if scalar was supplied instead of vector this scalar will be the x component, the rest will be zero. On the other hand if scalar is expected and vector is supplied then the length of the vector is taken.
Some commands behave similarly they are described together: Simple commands (Arrow, Color, Cut, Dir, Position, Show, Size, Texture), The rest is detailed one by one: Transparency, Print. Var, New)
They all perform actions on the properties of an individual body. Order does matter. Changing a property in a command effects its usage in a command placed after it. If a parameter is not supplied zero or nulvector is taken as default.
All of these have the same last two parameters: expr;type] that is described below
expr: An arbitrary expression. The result is taken to be a scalar if that is larger than zero the constraint is performed. If missing, default is 1.
type: An arbitrary expression. The result is taken to be a scalar and truncated to an integer if this is equal to the group type (the number behind the check box label) then the command is interpreted to only this group. If missing all groups are considered.
Example:
Arrow[...;;] All bodies are plotted with arrows.
Arrow[...;;1] All bodies of group 1 are plotted with arrows.
Arrow[...;dx>1;1] All bodies of group 1 which have a diameter larger than 1 are plotted with arrows.
Arrow[...;dx>1;] All bodies which has a diameter larger than 1 are plotted with arrows.
Show[dx>1;1] Show only bodies in group 1 which have a diameter larger than 1 (other groups are not effected).
Description:
GL handels very nice objects hiding eachother but transparent objects must be drawn after non-transparent ones. That also implies that transparent objects hiding eachother are not handeled correctly. At least up to my knoledge. So first non-transparent objects are drown then transparent ones.
In the current state mozi checks each body twice. It would be too much unneccessary duty to do the constraint calculation twice too. So Transparency command is handeled first then the transparency of each object is determined and then in each routine only those objects who are the correct transparency calculated. This should also be considered when order of changes is important.
An other annoying consequence of this is that by removing the command does not change back the value to the original. You have to do it by hand.
Apart from this Transparency command behaves as a Simple command.
A typical example of lazyness but may consider as a feature because this command may have the place elsewhere. This command prints text to the GL screen. You may print the value of any variable to the screen. Unfortunately, only one font can be used that is specified by the command line, the rc file or mozi falls on the hardcoded location.
There are two ways of positioning the text. One is the position on the screen. In this case x and y coordinates may vary from 0 to 1 representing the screen fraction. In this case there is no depth, the sign of the x coordinate decides that the text is placed before or behind the objects. The second method is distinguished by supplying vector variable at the y parameter which then means a position as the objects in the datafile. Thus one can print text next to an object that moves with it. In this case the value of the parameter of the x coordinate is neglected if its sign is negative the fonst will be transparent.
The format in general follows that of printf with restrictions and modifications. Here is the summary of the differences that may not be complete
This command has two usage: Either it may alter global variables like object orientation and position, or define variable. The use of the latter can be manyfold. The 'Var' command is calculated before changing the properties of the bodies and can be much faster when looking for the maximum or the minimum of something.
You may set the global orientation and the position of the system. You may set them as a vector or componentwise. The first parameter of 'Var' must be one of the following:
Note, that if any of them is set the change with mouse is only temporary. Redraw changes back the position.
Example:
You want to look around the system: Var[gl.phiy;fpos]
This changes the point of view by one degrees at each frame. This is at every timestep or if frame repeat is set to some value the same configuration is shown from different angles.
The first parameter is evaluated to an integer. This can be anything from 0 to 3*body_alloc (see -b command line option). Afterwards the value can be used in var() function.
It is advisable to put any neccessary Array Functions in a Var argument otherwise mozi slows down enormously.
This command lets the user to create new objects. This command has a very complex interpretation and may not be free from bugs. There are three levels of new objects creation: one single new object, maximum one new object for each body, N objects for each body (with N number of bodies).
The new objects (all of them even if generated by multiple New commands) will have the type one larger than the maximum different objcet types in the datafile. (E.g. demo.dat: Wall(1), Cylinder(2), Ball(3), so new objects will have type 4).
The number ('num' variable) of the new objects starts from body_alloc-1 and decreases. This is done to haev the possibility to save them from timestep to timestep and trace a particle.
If second parameter left empty, only one object will be created. Ideal for marking positions, angle etc. All simple variables refer to the very first object in datafile.
Example:
To Mark the height of the center of mass of the balls by a yellow disk in demo, use the following constraint:
Var[0;Av(z);1;3] New[disk;;0.005;var(0)*i_z;;Yellow]
First the zeroth variable is assigned the value of the average z coordinate (all balls are identical) of the balls (type=3). Then a single disk is created by 'New' at height var(0). See resulting image.
Mozi evaluates expr for each body and for which it finds it true creates a new body with the parameters supplied. All simple variables refer to the same body.
Example:
Show direction of each ball in demo by and arrow. Change to Radian units and type:
New[arrow;type=3;0.002*i_x+0.0001*i_z;Pos;Rot(Orient,phi,i_z);Yellow]
The created object will be an arrow. It is created only for type=3 bodies (Balls). Length is 0.002 width is 0.0001 units. Its position is the same as the ball it belongs to. Orientation must be get by the above rotation as in the standard data format orientation is supplied by an axes and an angle. If the z axes is rotated arount the axes (Orient) by phi radians we get the corrrect orientation.
Result is on this image.There is an array variable (i) in mozi. If it appears in an expression it is evaluated with each body and i is substituted by the num variable of the cycle. This will be explained later in detail. In 'New' if it appears in any of parameters (1-4, Expr, Dimension, Position, Direction) the 'New' command is processed N2 times. This allows to create objects depending on the properties of two objects. Use carefully as it can be extremely slow in large systems.
Example:
In the demo file we want to draw a line between those particles which touch each other. We explain the corresponding constraint step by step. See also the image.
New[cylinder;(P.type(i)=3) && (type=3) && (abs(Pos-P.Pos(i))<(dx+P.dx(i))/2) && (i>num); (dx+P.dx(i))/2*i_z+0.0002*i_x; P.Pos(i); Pos-P.Pos(i);Yellow] Size[dx/2;1;3]
Explanation:
mozi understands normal mathematical expressions (e.g.: 1+2), groupped with paranthesis ('()' or '{}'). The functions are discussed below. All numbers are considered double precision scalar or vector even if the result is expected to be an integer. There is no error message for vector/scalar mixup. The only error messages you may get if the formula you supplied cannot be converted to RPN (Reverse Polish Notation) format. These errors include unpaired brackets, not enough operand for a function or unknown symbols.
mozi is in generaly case insensitive only the scalar variables are case sensitive.
The following groups are discussed:
Numbers are treated as scalar constants. mozi understands decimal point numbers and scientific (e.g. 1.5e-3) format.
Name | Value |
pi | 3.14159265... |
e | 2.7182818... |
wall | 1 |
ball | 2 |
cylinder | 3 |
disk | 4 |
force | 6 |
arrow | 12 |
cone | 13 |
The first three vectors are the principal axes, the fourth the nul vector, the rest are color definitions.
Name | Value | Name | Value | Name | Value | Name | Value |
i_x | (1,0,0) | i_y | (0,1,0) | i_z | (0,0,1) | Nul | (0,0,0) |
White | (1,1,1) | Black | (0,0,0) | Red | (1,0,0) | Green | (0,1,0) |
Blue | (0,0,1) | Yellow | (1,1,0) | Magenta | (1,0,1) | Cyan | (0,1,1) |
Orange | (1,0.66,0) | Brown | (0.5,0.11,0.11) | Grey20 | (0.2,0.2,0.2) | Grey40 | (0.4,0.4,0.4) |
Grey60 | (0.6,0.6,0.6) | Grey70 | (0.7,0.7,0.7) | Grey80 | (0.8,0.8,0.8) | Grey90 | (0.9,0.9,0.9) |
Red2 | (0.75,0,0) | Red3 | (0.5,0,0) | Green2 | (0,0.75,0) | Green3 | (0,0.5,0) |
Blue2 | (0,0,0.75) | Blue3 | (0,0,0.5) | Yellow2 | (0.75,0.75,0) | Yellow3 | (0.5,0.5,0) |
Purple | (0.6,0.11,1) |
Description | Scalars | Vector | ||||
Number/type: | num | type | ||||
Size/force index: | dx | dy | dz | i1 | i2 | Dim |
Position: | x | y | z | Pos | ||
Orientation: | rx | ry | rz | phi | Orient | |
Color: | cr | cg | cb | ca | Col | |
Coordination number: | Z | |||||
Velocity: | vx | vy | vz | Velo | ||
Force: | fx | fy | fz | Force | ||
Angular velocity: | omx | omy | omz | AngVelo | ||
Torque: | tx | ty | tz | Torque | ||
Tr. Velocity: | tvx | tvy | tvz | TrVelo | ||
Tr. Force: | tfx | tfy | tfz | TrForce | ||
Tr. Angular velocity: | tox | toy | toz | TrAngVelo | ||
Time: | ps | t | fpos |
Variables are the parameters of the objects read from the data file. In general data file contains a lot of information. Refer to fileformat.txt supplied with mozi for a detailed description. In normal visualization mozi uses the Size, Position and the Orientation fields. Only Size is obligatory.
Most of the parameters are vectors (like 'Pos' position) but its components are also available. In some cases when the parameter is a group of scalar they are also available as vector to facilitate the handling of them. The color (Col=(cr,cg,cb) (Red,Gree,Blue), and Dim=(sx,sy,sz) (X dimension, Y dimension, Z dinemsion).
These variables are case sensitive in mozi.
If these variables are used in a constrant they are filled up with the parameters of the actual body. For example: Size[Dim*2] Position[Pos*2] will make the system and every paricles twice as big as both positions and size are doubled.
If you change any of them by a command, let's say 'Pos' by the Position command, then in commands after this the modified value will be used. So be careful with the order of the commands.
Here we describe the meaning only of the variables which is not trivial. In most cases the meaning is clear for example if you supply Tr. Velocity in the datafile then mozi knows from the parameter part of the type fields. The the values are read and stored in scalar variables tvx,tvy,tvx and vector variable TrVelo of each particle.
Using other particle's parameters
It is possible to use other variable's parameters but you have to know it's number (num).
P.Pos(3)
The above variable will take the position (which is a vector) of the object with num=3. With this method you can include in a constraint any property of any body. See 'New' example for a demonstration.
Unary functions expect one argument between parenthesis. Except for 'norm' all functions work with scalars. If vector is given as argument then its length [=sqrt(x*x+y*y+z*z)] is taken as argument. So for example abs(v) gives the length of a vector.
sin | sinus (s) |
cos | cosinus (s) |
tg | tangent (s) {=sin(s)/cos(s)} |
ctg | cotangent (s) {=cos(s)/sin(s)} |
asin | arcussinus (s) |
acos | arcuscosinus (s) |
atg | arcustanget (s) |
actg | arcuscotangent (s) |
sqrt | square root of absolute value (s) {=sqrt(abs(s))} |
sqr | square (s) |
abs | absolut value (s) |
sgn | sign function (s) {=1 if s>0; =0 if s=0; =-1 if s<0} |
exp | exponential (s) |
log | natural logarithm (s) |
int | integer part (s) |
norm | sgn (s), normalization (v) {=v/abs(v)} |
var | value of variable int(s): (s) return value depends on the definition in the Var command |
gbeg | num of the first body of group (s) |
gnum | number of bodies in group (s) |
Binary operators are placed between its two arguments like 1+2. The order follows the usual mathematical convention and listed below. The smaller value at order shows which operations are made first. Two operators haveing the same order are evaluated in the writing order at the same step (e.g. 6*4/3*2=16). If you want to change the order use parenthesis [e.g. (1+2)*3=9].
The most contraversal part of the constraint implementation in mozi is the dealing with binary operations dealing with mixtures of vector and scalar. There is no way to know in advance the nature of some quantities so no error message is printed e.g. for dividing by a vector but some 'reasonable' answer is made.
Description:
Notations:
If x1 or x2 is a vector then s1=abs(v1) and s2=abs(v2). For Vector function see Vector functions.
[S] or [V] indicate scalar or vector return value
Operator | Order | s1,s2 | s1,v2 | v1,s2 | v1,v2 |
^ | 1 | Power [S]=s1^s2 | Vectorial product [V]=v1^v2 | ||
* | 2 | Multiplication [S]=s1*s2 | Scalar product [S]=v1*v2 | ||
/ | 2 | Division [S]=s1/s2 | |||
% | 2 | Integer modulus [S]=s1%s2 | |||
+ | 3 | Addition [S]=s1+s2 | Addition [V]=v1+Vector(1,1,1)*s2 | Addition [V]=v1+v2 | |
- | 3 | Substruction [S]=s1-s2 | Substruction [V]=v1-Vector(1,1,1)*s2 | Substruction [V]=v1-v2 | |
>= | 4 | [S]=(s1>=s2) The result is 1 if true and 0 if false | |||
= or == | 4 | [S]=(s1==s2) The result is 1 if true and 0 if false | |||
<= | 4 | [S]=(s1<=s2) The result is 1 if true and 0 if false | |||
!= | 4 | [S]=(s1!=s2) The result is 1 if true and 0 if false | |||
> | 4 | [S]=(s1>s2) The result is 1 if true and 0 if false | |||
< | 4 | [S]=(s1<s2) The result is 1 if true and 0 if false | |||
& or && | 5 | [S]=(s1&&s2) The result is 1 if both are positive and 0 otherwise | |||
| or || | 5 | [S]=(s1||s2) The result is 1 if any of them is positive and 0 otherwise |
The following subset of functions is called Vector functions. They do most common vector operations except from vectorial and scalar product which is done by binary operators. The parameters of these functinos are seperated by comma ','.
The major difference between these functions and the previous ones that they work only with correct function arguments. If scalar is supplied instead of vector or vica versa they do not do anything. In that case the result will be the first argument irrespect of its type.
Function | Parameters | Description |
Rot | r[v]=Rot(t[v],phi[s],x[v]) | Rotates vector x around axis t with angle phi |
Mirror | r[v]=Mirror(t[v],x[v]) | Mirrors vector x on the plane perpendicular to t |
Lincomb | r[v]=Lincomb(a[v],b[v]) | Componentwise sum: r_x=a_x+b_x, r_y=a_y+b_y, r_z=a_z+b_z |
If | r[s/v]=If(e[s],t[s/v],f[s/v]) | If e>0 then r=t otherwise r=f. t and f must be of the same kind |
Vector | r[v]=Vector(x[s],y[s],z[s]) | Returns vector given by the three components |
Comp | r[s]=Comp(x[v],c[s]) | Returns c component of vector. c must be 0, 1, 2 |
Projl | r[v]=Projl(p[v],x[v]) | Projects x on the vector p. The result is one dimensional |
Projp | r[v]=Projp(p[v],x[v]) | Projects x on the plane perpendicular to p |
Array functions have arbitrary number of parameters, seperated by comma ','. The most general usage of them is to average, get the minimum, etc. of some material property.
The second usage of the array variable 'i' apart from the command 'New' is with these functions. If the array variable 'i' appears in one of the arguments of these function then 'i' is substituted by each 'num' for which the expression and type of the command fulfills. In such a way the number of arguments of these functions is increased.
Let us note that of course this can be very time consuming. To reduse time of the constraint calculation use these commands preferably only with 'Var' command. 'Var' command is evaluated seperately from the other commands and before them. Calculating the minimum of a property in 'Var' needs N operations (N being the number of particles), while using it in a Simple command (e.g. Position) takes N2 operations as the minimum is calculated at the drawing procedure of each particle.
The only function that is different from the others is 'Foreach'. This is used as an argument of the other functions if the parameter list should be further restricted. This may happen if two of these appear in one command.
The only function that is different from the others is 'Foreach'. This is used as an argument of the other functions if the parameter list should be further restricted. This may happen if two of these appear in one command.
Function | Description |
Min | Minimum of arguments |
Max | Maximum of arguments |
Av | Average of arguments |
Sum | Sum of arguments |
Minp | num of minimum of arguments |
Maxp | num of maximum of arguments |
Foreach | returns num only if argument is true (>0) |
The movie creation is done with Mesa off screen rendering and mpeg_encode. Unfortunately, this does not work with nvidia accelerated driver. We could not find other solution than to have two versions of mozi. One is compiled with the accelerated GL library with -D _NoMesa option. This version does not allow movie creation but still you can make snapshots the other version is compiled with the non-accelerated libraries. It is a little slower but can make mpeg movies. See also Compilation section.
After pressing 'Create movie' button a new window appears. Very few parameters can be set here so set everything before coming here. In the created mpeg file every active constraint remains in effect.
Here is the detailed description of the parameters
Under Linux a fork is done so an other process is generated for the movie creation. You may continue with playing around in mozi. This is useful if you want to make movies with the same setup form the same view with different settings. Just close the windows when you finished and wait for the result.
Note: At the beginning there was an other program called dat2mpg for the movie creation. Which was very convenient if one wants to create mpegs on computers without display. That time movie created a configuration file that was given as an input to dat2mpg. With the appearance of constraints the information that one must send became so enormous that I gave up developing two codes similarly. Maybe it would be nice to free the file reading and the GL plotting from all gtk and put in a separate file that could be included in both codes. For the time being I am happy with the one program concept.
Note 2: In older versions there was a possibility to change the origin in the above window. Since now it can be done by constraints it is removed from here. The present system is more convenient since you can preview what you will get.
That is a part that should improve a lot. The ideal state would be to be able to save the current configuration entirely and go back to the same state after new startup also with a different datafile. I am working on it. Please, be patient. Once it is done I will experience with a mozi free from gtk to be able to use in command line.
At present .mozirc is first searched for in the current directory, if not found $HOME is searched for. Writing always goes to the global one. (TODO: local writing should be enabled.)
rc file is written if the menupoint is selected. Or the -w command line switch is selected.
List of parameters written into .mozirc
The latter two may include several lines and are rewritten even if you do not make mozi write rc file. The other options are changed only at your request.
In some cases it may happen that mozi crashes at the wrong time or multiple mozi session destroy or mess up the constrain section of the rc file then please take a look at .mozirc~ and .mozirc_ files. And if you find them better copy them back. In general .mozirc~ is the rc file before the last and .mozirc_ the so far longest file.
Mozi works on Linux and windows. However for the latter you need really a hard work to do. A detailed description should come soon.
Needed libraries
Just type make and hope the best