I am using the fem_equiv_preview() to highlight nodes to be equivalenced by a session file. The positions are highlighted by circles, but when I move the model, the circles disappear. How do I maintain the circles until they are manually erased.
Because Patran is written in PCL all it's functionality is called through PCL calls, in many cases the PCL is a wrapper around a C/C++/Fortran routine. As you observe there are no argument descriptions in the !!TRACE output.
The Patran documentation is the only source of descriptions available to us, so using that to find something is the first "skill".
Using the "search"option and suitable wild card * syntax can generally find you every reference to something relevant from all the available documentation, e.g. *segment_cre* when looking for segment create:
using something too broad in scope like ga_* may result in too many references to chase them all down - but sometimes even that is preferable to nothing.
The reason that only hundreds of PCL routines are documented is that all the others are considered the "internal" code (remember it is the code that Patran is written in) and users do not need access to them. It allows development to change them regardless between versions. It is very rare that a documented function call will ever change so that upwards compatibility of pcl between versions is preserved as far as possible.
PCL calls are pretty much named according to Application_Action_Object_Method,
The application name is abbreviated to a few letters and is not always obvious unless you know the history. Geometry has multiple "engines" inside it so,
asm_ = Analytical Solid Modelling this is the original Patran-G analytical cubic geometry engine - based on Coons patch formulation (https://en.wikipedia.org/wiki/Steven_Anson_Coons) and extended into 3D with the "tricubic hyperpatch". With Patran 3 came a new geometry engine the Single Geometric Model (SGM) capability. "SGM accesses geometry data, topology, and evaluators from the CAD (Computer Aided Design/Drafting) system without transformation and establishes and maintains associativity with the corresponding MSC/PATRAN finite element entities throughout the entire design and analysis process." SGM is capable of working with CAD geometry in it's native math format, Bezier, Nurb etc through a procedural mapping to a parametric space. These are the SGM_ geometry commands. finally you get the Parasolid geometry kernel and library of calls these are the "ge_..." routines.
other application abbreviations:
ga= graphics, gm = graphics manager, ui = user interface, fem=finite element, res=results etc.
If you know the application abbreviation then looking at the "Index" tab in the documentation and using the relevant letter ("F" for FEM etc) you can often scan the available documented routines to find what you want (the best way is knowing how to do it in Patran and use the session file function that is documented).
Failing finding relevant calls in the docs using the !!TRACE command to see what calls are being made is kind of a last resort (but very useful).
OK, you find a function call that is seemingly just what you want in a TRACE but you have no idea what the arguments are. Run Patran, open a db and then in the command window start trying out some pcl. Firstly you call the name with no arguments like:
ga_view_attributes_get()
$# (PCL) Missing arguments to function
$# Execution aborted
Now start guessing and so you create an integer variable and try that:
integer ahint
ga_view_attributes_get(ahint)
$# (PCL) Mismatched function argument: VIEW_NAME
that was a nice clue - it is a name, so probably a string [32]
so try a string
string ahstr[32]
ga_view_attributes_get(ahstr)
$# (PCL) Missing arguments to function
This showed the first argument was a string, now add a second argument
ga_view_attributes_get(ahstr, ahint)
$# (PCL) Mismatched function argument: CLIPPING_FLAG
this time it says wrong argument for name "CLIPPING_FLAG"
great - it is probably a logical (flag)
so, I'm now getting confident how to do this so jump to
logical ahlogi
ga_view_attributes_get(ahstr, ahlogi, ahint)
$# (PCL) Mismatched function argument: CAPPING_FLAG
another logical ... and continue. Note that the name of the argument gives you clues not only to its type but also what it does - there is generally good agreement between an arguments name and what it represents.
This puzzling out of the argument list sometimes works and sometimes is impossible to work, particularly with arrays. But it is surprising what you can deduce.
Often the best way is to post in the forum what you are trying to do and someone may have already figured out what might be useful for you and maybe already have a function they'll share.
Because Patran is written in PCL all it's functionality is called through PCL calls, in many cases the PCL is a wrapper around a C/C++/Fortran routine. As you observe there are no argument descriptions in the !!TRACE output.
The Patran documentation is the only source of descriptions available to us, so using that to find something is the first "skill".
Using the "search"option and suitable wild card * syntax can generally find you every reference to something relevant from all the available documentation, e.g. *segment_cre* when looking for segment create:
using something too broad in scope like ga_* may result in too many references to chase them all down - but sometimes even that is preferable to nothing.
The reason that only hundreds of PCL routines are documented is that all the others are considered the "internal" code (remember it is the code that Patran is written in) and users do not need access to them. It allows development to change them regardless between versions. It is very rare that a documented function call will ever change so that upwards compatibility of pcl between versions is preserved as far as possible.
PCL calls are pretty much named according to Application_Action_Object_Method,
The application name is abbreviated to a few letters and is not always obvious unless you know the history. Geometry has multiple "engines" inside it so,
asm_ = Analytical Solid Modelling this is the original Patran-G analytical cubic geometry engine - based on Coons patch formulation (https://en.wikipedia.org/wiki/Steven_Anson_Coons) and extended into 3D with the "tricubic hyperpatch". With Patran 3 came a new geometry engine the Single Geometric Model (SGM) capability. "SGM accesses geometry data, topology, and evaluators from the CAD (Computer Aided Design/Drafting) system without transformation and establishes and maintains associativity with the corresponding MSC/PATRAN finite element entities throughout the entire design and analysis process." SGM is capable of working with CAD geometry in it's native math format, Bezier, Nurb etc through a procedural mapping to a parametric space. These are the SGM_ geometry commands. finally you get the Parasolid geometry kernel and library of calls these are the "ge_..." routines.
other application abbreviations:
ga= graphics, gm = graphics manager, ui = user interface, fem=finite element, res=results etc.
If you know the application abbreviation then looking at the "Index" tab in the documentation and using the relevant letter ("F" for FEM etc) you can often scan the available documented routines to find what you want (the best way is knowing how to do it in Patran and use the session file function that is documented).
Failing finding relevant calls in the docs using the !!TRACE command to see what calls are being made is kind of a last resort (but very useful).
OK, you find a function call that is seemingly just what you want in a TRACE but you have no idea what the arguments are. Run Patran, open a db and then in the command window start trying out some pcl. Firstly you call the name with no arguments like:
ga_view_attributes_get()
$# (PCL) Missing arguments to function
$# Execution aborted
Now start guessing and so you create an integer variable and try that:
integer ahint
ga_view_attributes_get(ahint)
$# (PCL) Mismatched function argument: VIEW_NAME
that was a nice clue - it is a name, so probably a string [32]
so try a string
string ahstr[32]
ga_view_attributes_get(ahstr)
$# (PCL) Missing arguments to function
This showed the first argument was a string, now add a second argument
ga_view_attributes_get(ahstr, ahint)
$# (PCL) Mismatched function argument: CLIPPING_FLAG
this time it says wrong argument for name "CLIPPING_FLAG"
great - it is probably a logical (flag)
so, I'm now getting confident how to do this so jump to
logical ahlogi
ga_view_attributes_get(ahstr, ahlogi, ahint)
$# (PCL) Mismatched function argument: CAPPING_FLAG
another logical ... and continue. Note that the name of the argument gives you clues not only to its type but also what it does - there is generally good agreement between an arguments name and what it represents.
This puzzling out of the argument list sometimes works and sometimes is impossible to work, particularly with arrays. But it is surprising what you can deduce.
Often the best way is to post in the forum what you are trying to do and someone may have already figured out what might be useful for you and maybe already have a function they'll share.
