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.
Thanks for the answer. I am aware of the described solution for preview of nodes to be equivalenced and also the meshing -> equiavalence -> preview. But I was looking for a way forward for a tool that I am working on where the preview and equiavalence nodes is included. Any suggestions for a function to preview the nodes, like the fem_equiv_preview() ? The one mentioned in the header shows the nodes temporarily, but they disappear when I translate/rotate the model.
I've now managed to create the circles using 'v_f_equiv_1.preview_nodes( nodes_in, nodes_out, tol )' by a session file. I have some difficulties deleting the markers again. Any suggestions for doing that other than using the Utilities/FEM-General/Equivalence Nodes/Reset Graphics ?
Hi, apologies but I've been unable to reply for a while.
You may have sorted this but in case not then here is the answer and also the methodology I used to find it that you may find useful.
Patran graphics, the user part anyway, is set up by creating "segments" and putting things into them (draw) to display. The calls for this are the "gm_segment_xxx" and "gm_draw_xxx" families of calls. Why point this out? Well, knowing the calls that must be happening you can begin to look how they are called by, in this case, the equivalence node display utility.
Start Patran with the -stdout flag (if your unfamiliar with this, edit the Patran desktop shortcut "properties" and add -stdout to the "Target:" setting).
Start Patran and you will now have the cmd output window visible on screen.
Open a small test db with some nodes to equivalence, open the utilities / FEM-General / Equivalence preview... utility.
Now type in the command line:
!!TRACE CALLS
this will start Patran echoing every pcl call to the output window (extensive, very extensive output). Now click on the Preview Nodes option, then click on the Reset graphics option. Then type in:
!!TRACE NONE
this turns off the call tracing - otherwise you get an enormous amount of output flooding the output window.
Looking at the content of the output window you will find at the "start"(after you turned on TRACE CALLS) something like:
[Call to bv_f_equiv_1.preview_cb]
[Call to ui_wid_get_vstring]
[Call to ui_wid_get]
[Call to bv_f_equiv_1.preview_nodes]
[Call to bv_f_equiv_1.segment_create]
[Call to bv_f_equiv_1.segment_delete]
[Call to repaint_graphics]
[Call to gm_viewports_refresh]
[Call to gm_xywindows_refresh]
[Call to gm_segment_create]
This shows that the bv_f_equiv_1.preview_cb that you used, calls bv_f_equiv_1.preview_nodes, that in turn calls bv_f_equiv_1.segment_create, that calls bv_f_equiv_1.segment_delete, then gm_segment_create. The indentation shows which routine is making the calls.
At the end of the trace after the reset graphics option was activated a similar type of sequence with a "bv_f_equiv_1.segment_delete" call.
So first guess is to try this as a call and hope that the graphics segment ID that the routine is using is stored in the routine as a classwide variable (fairly common practice) and not required as an argument .
do a preview and then type in the command:
bv_f_equiv_1.segment_delete()
it clears the graphics, so this looks like the call you needed.
So many lines to explain how I found the necessary call, but this technique is so useful that it was worth detailing, hopefully it makes reasonable sense.
Thanks alot for your reply ! It was very helpful - both for solving the specific problem I had, but also for further development of embedded functions in Patran.
I have now tried your suggestion regarding the -stdout flag and it seems to be very beneficial - so again, thanks a lot ! Previously I have had some difficulties, because Patran did not write all the calls in the session file.
I was wondering if you have any tricks on how to identify what input/output each function expects/demands. I've been looking in the MSC Combined Documentation, but most of the functions are not explained and does not exist in the documentation.
Are you aware of another library where the functions are described or do you have any suggestions on how to determine the inputs and outputs ?
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.
