 |
Session Support |
Session Support
| <<< Bulletin Board | Chapters | Error Handling >>> |
This chapter introduces those areas of functionality that an application can use to control and get information about a Parasolid modeling session.
PK_SESSION_ask_memory_usage returns the amount of memory currently occupied by the model data structure. This can be tested if storage space problems are anticipated:
PK_BODY_ask_memory_usage returns the amount of memory currently occupied by a body's data structures.
To control the numerical range of tag values, an upper bound range of Parasolid tag numbers can be specified by calling PK_SESSION_set_tag_limit.
Normally the tag limit is not expected to be changed during a Parasolid session. However, if it is changed, it is not affected by either session or partition roll operations - it remains at the value most recently set.
PK_SESSION_ask_tag_limit returns the limit set, and PK_SESSION_ask_tag_highest confirms the maximum tag value currently being used in Parasolid.
A session transmit file, or snapshot, is an image of a session at a particular instant, which can be loaded to re-create the session. Typically snapshots are used to:
PK_SESSION_transmit is used to create a snapshot file, in one of these formats:
There are four formats that can be used for the file, which should be provided in the application Frustrum as required.
| Format | Frustrum requirements |
|---|---|
|
this format uses the application frustrum functions which are registered by PK_SESSION_register_applio |
|
Note: Text format must be used if the snapshot is to be used to report a Parasolid fault. |
For further information about transmit formats see Chapter 2, "File Handling", of the Parasolid Downward Interfaces manual.
PK_SESSION_receive restores a snapshot into the same version of Parasolid as it was transmitted. This has the following effects on the session:
PK_SESSION_receive_version returns information about the version of Parasolid used to create a session transmit file.
A journal file is a record of all calls to Parasolid functions and the arguments returned from those calls. These files are intended as a debugging tool at two levels:
Control of journalling is provided by:
A PK function which returns an error to the application journals a comment describing the error code and its severity (except when the user error handler longjumps over Parasolid).
The generation of journal files is described in Chapter 2, "File Handling", of the Parasolid Downward Interfaces manual.
When journalling is on, PK_SESSION_comment can be used to assist deciphering files from the application. It enables a comment to be added to a journal file which can be used to link the PK function call to what the application was doing.
The application's GO functions are permitted to make calls to PK functions. This might be used, for example, to get data from an attribute attached to an entity being rendered. Only one level of recursion is allowed.
A user field consists of a number of bytes of memory, allocated to every entity in a session, in which data needed by the application can be stored. The data contained in the user field of each entity can be set and read individually, using PK_ENTITY_set_user_field and PK_ENTITY_ask_user_field.
The decision of whether to use user fields is fundamental to the architecture of the application. When deciding whether or not to use them compare the relative benefits of user fields and attributes:
Users fields are enabled by passing the required length to PK_SESSION_start, and the current setting is returned by PK_SESSION_ask_user_field_len.
For further details of attributes see Chapter 47, "Attributes".
When Parasolid requires memory for workspace or modeling operations, it calls the FMALLO function (PK_FMALLO_f_t) that you supply in the frustrum. Parasolid provides you with two functions that let you manage the minimum amount of contiguous space that Parasolid requests when it calls FMALLO. In some circumstances, changing the value of this minimum amount of memory may improve performance, both in terms of time and memory. For example, if your application's memory management works on blocks of a certain size, using the same block size in Parasolid may improve performance slightly.
You can use PK_MEMORY_set_block_size to set the minimum memory that Parasolid requests via FMALLO. This function lets you specify a minimum block size between about 1/8 Mbyte (the default) and 16 Mbytes. It can be called at any time, whether or not the modeler is running. To return the minimum block size to Parasolid's default, call PK_MEMORY_set_block_size with an argument of zero.
You can use PK_MEMORY_ask_block_size to return the current minimum block size.
If you stop the modeler, the minimum block size is always reset to the default value.
|
Note:
1. Increasing the block size does
not allow Parasolid to perform bigger modeling operations. Parasolid always requests the amount of memory it needs for a given job. Larger block sizes simply mean that fewer blocks are needed when passing memory to Parasolid, which in turn means that FMALLO and FMFREE are called less often. Note: 2. The more you increase the minimum block size above the default, the less likely it is that Parasolid will have enough free memory to release back to the operating system. This may affect the performance of other processes on the system. Note: 2. The exact limits of the block sizes you can set are platform dependent. If you need to know these limits exactly, experiment by setting small and large values for PK_MEMORY_set_block_size and then using PK_MEMORY_ask_block_size to see what values are returned. |
A number of functional areas within Parasolid have been adapted for symmetric multi-processing (or parallel processing) via the multi-threading environments supported under Windows NT. This can improve the performance of Parasolid when executing on multi-processor platforms.
SMP operation within Parasolid is controlled via the following functions:
| Function | Description |
|---|---|
SMP can be enabled/disabled at any time during a session.
|
Note: For optimum performance, we recommend that SMP is enabled with one thread per processor. You should not enable SMP on single processor machines. |
Depending on the platform that your application runs on, you may need to specify the stack size of threads used by Parasolid SMP. Although the default stack size for the system is usually sufficient, this is not always the case.
The following functions allow you to set and enquire the stack size of SMP threads:
| Function | Description |
|---|---|
|
Sets the size of the stack allocated to Parasolid SMP threads. |
|
|
Returns the size of the stack allocated to Parasolid SMP threads. |
For both functions, a zero value means that the platform default stack size is used.
This section gives general guidelines for setting the stack size on each of the platforms that are SMP-capable.
The default thread stack size in Windows NT is 1 MByte. This is probably sufficient for all purposes, so you should never need to set the stack size for Windows NT applications, unless you need to reduce it for simple operations.
|
Note: In addition to PK_SESSION_set_smp_stacksize, the default may be changed on Windows NT by relinking the application and the Parasolid DLL with an appropriate STACKSIZE value in the .DEF file. |
The default thread stack size in Solaris 7 is 1 MByte for 32-bit processes and 2 MBytes for 64-bit processes. These values are probably sufficient for all purposes and you should never need to set the stack size for Solaris applications, unless you need to reduce it for simple operations.
HPUX V10.30 uses a POSIX-compliant threads interface with a default thread stack size of only 64 KB. This is far too small for complex modeling, and so you probably need to set the stack size when enabling SMP for HPUX applications.
Alternatively, your application can change the default size for its process, using a platform-specific routine provided by Hewlett-Packard. The advantage of this is that the operating system attempts to cache default thread structures ready for activation. This makes starting SMP quicker than if Parasolid set its stack size on each thread invocation.
For example, to establish a stack size similar to the system default for Solaris, you could use the following code:
PK_SESSION_smp_o_t opt; size_t new_stk = 256 * 1024 * sizeof(char*), old_stk; PK_SESSION_smp_o_m( opt ); if (pthread_default_stacksize_np( new_stk, &old_stk ) != 0) { // OS has rejected the request so let Parasolid do the work PK_SESSION_set_smp_stacksize( new_stk ); } PK_SESSION_set_smp( &opt ); |
Enabling SMP within Parasolid can modify the order in which results are returned from particular modeling operations. These operations are described below.
Whenever reporting faults to Parasolid Technical Support, always specify whether or not SMP is enabled.
If a boolean operation results in several distinct bodies being created, the order of the bodies returned may vary when SMP is enabled within Parasolid. This also applies to the tag persistence rules with respect to the value of the target body tag being applied to any one of the returned bodies.
For example, if Parasolid SMP is enabled and a boolean subtract operation returns more than one resultant body, Parasolid does not guarantee:
If PK_BODY_check is to return several errors, the order of the errors in the returned structure may vary if SMP within Parasolid is enabled.
When generating wireframe data via the Graphical Output (GO) with SMP enabled, Parasolid does not guarantee the order of information output via the GO. More specifically, depending on the state of SMP within Parasolid, the application programmer should note the following characteristics of the GO interface:
For example, when sketching a body:
As functions are added to Parasolid and improvements made to the software, the behavior of some older function may change.
Most variant capabilities of Parasolid can be controlled via switches in the options structures passed to individual PK functions. Some variants are so encompassing that they are distinguished by explicit global settings, e.g. general topology. A few are neither.
While applications normally cope, it may not be possible for a particular application to be corrected at that time. Parasolid may provide a switch to provide the previous behavior in such cases; such a switch will be removed at some future release of Parasolid when the application has been amended.
|
Note: Later customers with no legacy data should never need to use such a switch. |
Such switches are manipulated by the two functions:
Current permissible values of PK_SESSION_software_option_t are:
|
Note: Applications which intend to use any of these switches should contact Parasolid Technical Support for advice or possible workarounds. |
| <<< Bulletin Board | Chapters | Error Handling >>> |