Runtime environment
This section contains a brief description of 'lv's runtime environment.
The purpose of this section is to give some additional hints to the
"advanced user" who wishes to customize her or his 'lv' installation,
or to understand how command line options can be combined.
It should be noted that the contents of this section is not very
interesting, except for the purposes mentioned, and can be ignored
for normal application of 'lv'.
Organization of the runtime environment
A standard 'lv' installation consists of a csh (C-shell) script named lv
and a subdirectory named lv_base/. Both items should be installed
at the same place, and the lv script's location should be part of
the user's $PATH environment variable.
Usually, a 'lv' session is started using
lv "STEP file" [ Options ]
This means, the session begins with the execution of the lv script.
This script will determine the hardware platform/operating system version
it is executed upon, and will check if an appropriate binary executable
is located in the lv_base/ directory. If this is the case, the
binary gets executed, and all arguments given to lv are handed over
to it.
Sometimes, it might be necessary to modify the lv startup script:
- New operating system versions might identify themselves differently, causing
the lvscript to terminate due to "unknown" hardware. An example was the
SGI operating system version 6.x, which identified itself as "IRIX64", whereas
elder versions identified as "IRIX". In such cases it is required to
enhance the "system detection" algorithm in the lv script.
- If for some reason it is not desired to install lv and the
lv_base/ subdirectory at the same place, the location-and-execution
scheme near the end of the lv script might be modified as desired.
- If you are using 'lv' only on one platform, you might want to bypass
the given lv script completely and invoke the appropriate
binary executable directly (using, for example, an alias definition in the
.login script, such as
alias lv /bin/lv_base/lv.SGI
and then remove the original lv script as a whole.
All the necessary ingredients for 'lv's operation are contained in the
lv_base/ subdirectory. Here is what they are good for:
- lv.???: 'lv' binary executable for a specific hardware platform.
??? can be
one of the following supported platforms:
- AIX: IBM / AIX operating system
- HPU: HP / HP-UX operating system
- LNX: PC platform / Linux operating system
- SGI: Silicon Graphics / IRIX operating system
- SOL: Sun Solaris 2.x (aka SunOS 5.x)
Note: The binary executables for different platforms have different names
so that it is possible to use the same installation directory (lv_base/)
for different platforms.
Note also that it depends on your installation which of these are actually present,
but at least one needs to be there...
- *.exp: EXPRESS schema files for the STEP application protocols that
'lv' supports. They are required by the underlying STEP toolkit for parsing
the STEP data that is given as an input. They are also used to display the
schema in "Schema" mode.
"*" is a placeholder for the actual schema name (e.g. config_control_design.exp
for AP203, automotive_design_cc02.exp for AP214 conformance class 2 etc.
The "*"-name of the schema has to match the entry in a corresponding STEP
file. It is found in the FILE_SCHEMA instance in the header section
(near the beginning) of a STEP file. 'lv' will analyze this entry in the
given STEP file and choose the corresponding *.exp file as the
description of the data model used. Therefore, if the entry in the FILE_SCHEMA
instance is wrong, 'lv' might produce syntax error messages (if instances are
found whose definition is not contained in the *.exp file), or it
aborts completely (if no corresponding *.exp file is found in lv_base/).
If you want 'lv' to read files corresponding to a new, previously
unsupported EXPRESS schema, in theory it is sufficient to put the EXPRESS
file into the lv_base/ directory. Look at the beginning of the
EXPRESS file: Except for comments, the first statement will usually be
something like:
SCHEMA sample;
In this example, "sample" is the schema identifier, the EXPRESS file
should be lv_base/sample.exp, and a corresponding STEP file should
have a FILE_SCHEMA instance that looks like
FILE_SCHEMA(('SAMPLE ...'));
There are, of course, some restrictions, such as:
- EXPRESS schemas have to be in longform, i.e., they have to be self-contained.
So-called shortform schemas cannot be processed.
- Since 'lv's implementation is centered around part 42 and certain
related STEP resources, the tool's behaviour is most useful if the EXPRESS
schema supplied is close to these areas. For other areas, problems and error
messages that are indicated by 'lv' might be more or less irrelevant.
- In particular, one should be very cautious using options that cause
'lv' to write modified STEP files, because there is no safety that 'lv'
will be able to satisfy all constraints and supply all attributes for such
new, untested EXPRESS schemas.
Note: The mechanism for selection of the appropriate EXPRESS schema for a
given input STEP file (see description above) implies that 'lv' cannot
manage several different schema versions (EXPRESS schemas that have
an identical schema identifier, but whose versions are to be distinguished
by a so-called 'ISO object identifier' that is provided in addition in the
STEP file header). For such situations, there is no real workaround at the
moment, except
- using only the version of the schema that is a superset of all other versions, or
- choosing an arbitrary other name for one version, and modifying the
corresponding STEP file's FILE_SCHEMA instance accordingly.
- lv_cfg.expr: A special EXPRESS schema that describes the
configuration file which can be used to customize 'lv'. The data model
described therein is very simple and straightforward but is not conformant
to STEP resources etc. Currently it contains only elements to predefine
colors that 'lv' should use for the presentation of geometry and decorations.
As a reference, this schema is given further below.
Note: This schema may not be modified or deleted.
- lv_cfg.stp: This is the configuration file, in STEP part 21 format,
compliant to lv_cfg.expr, that 'lv' loads automatically if it is present
and if no other configuration file is explicitely given using the
-c option.
See further
below for an example of a configuration file.
Note: since the built-in default colors for 'lv' do not meet most people's
good taste, 'lv' even expects this file to be present, and issues a warning
if it is not found during startup.
- p21.hdr: Another EXPRESS schema that describes the
instances in a STEP file's header section. This file is required by the
underlying STEP toolkit. It may not be modified or deleted.
- doc/: This subdirectory contains the digital documentation for
'lv' and the supported exchange formats (in HTML format). It is divided
into corresponding subdirectories (doc/help/, doc/step/, doc/vdafs/,
doc/iges/). Depending on the completeness of the installation, some of
them may be empty.
Note: If the browser window and the online documentations are not required,
this subdirectory or parts of its contents can be safely deleted in order
to save disk space.
Here is, as a reference, the contents of lv_base/lv_cfg.expr:
SCHEMA lv_configuration;
TYPE label = STRING;
END_TYPE;
ENTITY colour;
END_ENTITY;
ENTITY colour_specification
SUBTYPE OF (colour);
name : label;
WHERE
wr1 : name IN ['background','highlight','mark','decorate',
'default', 'border', 'isoline'];
END_ENTITY;
ENTITY colour_rgb
SUBTYPE OF (colour_specification);
red : REAL;
green : REAL;
blue : REAL;
WHERE
wr1 : {0.0<=red<=1.0};
wr2 : {0.0<=green<=1.0};
wr3 : {0.0<=blue<=1.0};
END_ENTITY;
END_SCHEMA;
Here is an example of a configuration file for 'lv':
ISO-10303-21;
HEADER;
FILE_DESCRIPTION(('Sample default configuration for lv'),'1');
FILE_NAME('lv_cfg.stp','Aug 15, 2001',('J.Kuebler'),('T-Systems'), '1.0','vi',
'self');
FILE_SCHEMA(('LV_CONFIGURATION'));
ENDSEC;
DATA;
#10=COLOUR_RGB('background', 0., 0., 0.2);
#20=COLOUR_RGB('default', 1., 1., 1.);
#30=COLOUR_RGB('highlight', 1., 1., 0.1);
#40=COLOUR_RGB('mark', 0.3, 1., 1.);
#50=COLOUR_RGB('decorate', 0.7, 0.7, 1.0);
#60=COLOUR_RGB('border', 1.0, 1.0, 1.0);
#70=COLOUR_RGB('isoline', 0.5, 0.5, 0.5);
ENDSEC;
END-ISO-10303-21;
In this section, a brief description of the sequence of steps is given
which 'lv' will perform after invocation. This sketch might help
identifying the source of runtime errors, and might also help to
understand how different command line options
can be combined, and what the effect of such a combination (i.e., the
sequence of their execution) may be.
- The first step is the processing of command line arguments. This follows the
following outline:
- If the option -ns is not present, the
X11 toolkit is initialized, causing all X11-specific arguments (like -display,
-fg) to be processed. At this very early stage, the connection to the X
server is established or 'lv' aborts.
- 'lv' checks whether the option -unsafe
is present. In this case, all "unsafe" options get unlocked.
- 'lv' now processes all options that are present and that it knows of
(if -unsafe is not given, "unsafe" options
are considered to be unknown).
- If after these steps, there is at least one command line argument remaining,
this is the name of the STEP file to process; 'lv' will now look into the
file's header to determine the exchange format, and in case the format is STEP, the
name of the EXPRESS file to load (see description of the
schema selection mechanism).
If the exchange format is not recognized, 'lv' aborts with an appropriate
error message.
If, in the case of STEP, no matching *.exp file is found in the
lv_base/ directory, 'lv' will stop now after
printing the names of all available EXPRESS schemas.
Note: To be able to process the exchange formats VDAFS and IGES, a schema
named vdafs_iges.exp has to be present in lv_base/.
- If, after these steps, there are no arguments remaining (i.e., no STEP
file is given), or more than one argument remains (i.e., an unknown option,
or an "unsafe" option when -unsafe was not
provided), or if the given options could not be processed properly (e.g.,
invocation like "lv test.stp -l" would be illegal, because the
-l option requires an additional argument that
specifies the logfile to use), 'lv' prints all "known" options and stops.
Note: The consequence is that an invocation using just "lv" will
print a list of all standard options, and an invocation using "lv -unsafe"
will print all standard plus the "unsafe" options.
- Next, 'lv' will read and interpret the configuration file (see above) if present.
- Finally, first the EXPRESS schema that had been determined, and then
the given input (STEP/IGES/VDAFS) file are read.
Further processing of the product data depends on whether 'lv' is in
interactive operation mode, or in batch operation mode.
Interactive operation
Definition: 'lv' runs in interactive mode if:
- The option -ns is not present and,
- The following options are also absent:
- -fb,
-fc,
-ff (filter b-reps, curve_bounded_surfaces, or faces),
- -as (make single part from assembly),
- -sp (split assembly into several files),
- -ca (create assembly from multi-solid part),
- -m2s (add shape_rep_rel for mapped_item assembly),
- -m2g (convert manifold to geometrically_bounded surface model),
- -g2m (convert geometrically_bounded to manifold surface model),
- -f2m (convert faceted_brep to manifold surface model),
- -rs (rotate base surfaces),
- -2mm (convert model to millimetre basis),
- -fmt (write reformatted input file),
- -rp (remove pcurves),
- -rvd (remove a b-rep's voids),
- -ncs (shift geometry towards origin).
- -rh (restructure mixed models),
- -scb ("paint" b-rep model),
- -rmg (remove coloring from product),
- -e2b (convert cylinders to b-spline), or
- -cp (create pcurves)
In interactive mode as defined, 'lv' will proceed as follows:
- activate -unsafe, that means that
the checks will also apply that go along with -unsafe
-u (see description).
- set the level of checks to 2 if not yet specified to be higher (see
description of -u option)
- check compatibility of data with the underlying schema,
- begin to display geometry,
- perform a -u2 check of the product (or
-u3 if specified on the
command line)
- go into idle mode.
Batch operation
'lv' runs in batch operation if the conditions defined above
do not apply.
Note: Admittingly it might be hard for a non-programmer to interpret this
negation of a mostly negative condition, but remember: This chapter is
not deserved for the innocent reader.
In batch mode, 'lv's operation is mainly controlled by the options supplied.
In case there are any repair type options
present, they are executed and the program terminates. Some (few) of them
can be combined in an useful manner, and the description that follows below
hopefully explains these cases. In case no repairing options are provided,
(i.e., basically just -ns was
supplied on the command line), 'lv' will check
(if -u is present) the product
and just produce a logfile.
This "check-type" operation set aside (i.e., only "Command line options"
("-mod.stp" file) and terminate.
Whether in these cases, a modified file ("-mod.stp") gets written, depends
on whether the actions taken did result in any changes in the
instance set. If any instances were deleted, modified, or created, then
'lv' will now write the "-mod.stp" file (see discussion at
-ns option).
The following order applies:
- If the option -sp was supplied, this
action is performed.
Remember (as said above) that this means in case
-sp was present,
'lv' writes the results,
i.e., any other options provided are not considered.
- If the option -u was supplied, 'lv' will
now perform a check whether all geometric_rep_items are contained in
a representation. If
-nr is absent, any
isolated geometric_rep_items are now deleted and thus excluded from
further processing.
- In case the option -2mm is given,
the model will now get converted to a millimetre basis. However,
processing then continues with the remaining options, if any.
- The next option that is executed , if present, is
-m2s. In this case, execution terminates
thereafter.
- The next option that is executed is
-as. Again, after this option was
processed, execution will terminate.
- Next, the filter options (i.e., -fb,
-fc, and
-ff) are processed: If any of them
are present, filtering is attempted (i.e., instances not specifically
given on the command line get erased), and no further operation is
performed.
The following options are then checked for presence and, if present, are
processed in the order given (each option present leads to immediate
termination after having been processed):
- -ca (create assembly for multi-solid part),
- -m2g (convert manifold to geo_bounded surface model),
- -g2m (convert geo_bounded to manifold surface model),
- -f2m (convert faceted_brep to surface model),
- -rp (remove pcurves),
- -rvd (remove a b-rep's voids), and
- -ncs (shift geometry towards origin).
Having reached this point, the next two options are executed by 'lv' if
present, without the consequence of terminating the program: 'lv' will
process them if present, and proceed:
- -scb ("paint" b-rep model),
- -rmg (remove coloring from product)
The next option will, if present, again cause 'lv' to terminate after its
execution:
- -rh (restructure mixed models).
The folllowing step is then performed without the possible consequence of
leaving the program:
- If the option -u was supplied, 'lv' will
now perform the accuracy checks for the geometry. Any detected problems
may cause repairs in the data if
-nr is not given. Also note that
during this step, some of the other options are processed implicitely,
like e.g.,
-va,
-np,
-ac,
-h2l,
-sa, and
-ex. Of these, especially the options
-np,
-ac, and
-sa are, however, also active during
other processing steps, e.g. during the rendering of the geometry for
the geometry display.
Control flows on as follows:
- Next, if any of the options
-rs,
-e2b, and/or
-cp are supplied, they are processed in
this order. If any of them was present, 'lv' will then
write results and terminate.
Note however that
these three options can be combined.
- At this point, 'lv' will analyze the assembly structures and presentation
information in the STEP file. Then, the logfile is created (refer to
description of
-l option for a discussion of the
file name used for the logfile).
Help Index
© lv: visit us on http://www.wundertools.de/
This page last updated: 1999/11/17