Ansys rst file

Ansys rst file


  • Reading ANSYS Mechanical Result Files (.RST) from C/C++ (Part 1)
  • Separating Ansys DB Database File Contents from RST Results File Contents
  • Post-Processing APDL Models Inside Ansys Workbench V15.0
  • One thing we have to decide is what type of data the client of our iterator will receive when they dereference it. For example, when we are iterating over the nodal geometry, the RST file contains the node number, the nodal coordinates and the nodal rotations.

    To represent this data, I create a structure like this: I think this is pretty self-explanatory. Likewise, if we are iterating over the element geometry section of an RST file, there is quite a bit of useful information for each element.

    The structure I use in that case looks like this: Again, pretty self-explanatory. Well, the reason is fundamental to the design of the STL. Remember that the primary reason iterators exist is to provide a bridge between generic containers and generic algorithms. However, any one particular algorithm may impose certain requirements on the underlying iterator for the algorithm to function appropriately.

    If the iterator supports jumping around a. Take a linked list container as an example. You cannot randomly jump around in a linked list in constant time.

    To get to item B from item A you have to follow the links, which means you have to jump from link to link to link, where each jump takes some amount of processing time. This means, for example, there is no easy way to cut a linked list exactly in half even if you know how many items in total are in the list.

    Many sort algorithms, as an example, obtain their efficiency by effectively chopping the container into two equal pieces and recursively sorting the two pieces. You lose all that efficiency if you have to walk out to the center. That is, at the lowest level, I have to answer the question, can I just move forward one step? After that, assuming I can move forward one step, can I only go through the range once, or can I go over the range multiple times?

    Truthfully, the forward iterator concept and the single pass iterator concept form level 1A and 1B of the iterator hierarchy. The next higher level of functionality is a bidirectional iterator. This type of iterator can go forward and backwards one step in constant time. Think of a doubly linked list. With forward and backward links, I can go either direction one step in constant time.

    Finally, the most flexible iterator is the random access iterator. These are iterators that really are like raw pointers. With a pointer you can perform pointer arithmetic such that you can add an arbitrary offset to a base pointer and end up at some random location in a range. Certain classes of iterators provide this level of functionality, namely those associated with vectors and deques. So, the question is what type of iterator should we support? But, my assumption is that the routines were designed to access the data sequentially.

    At least, if I were the author of the functions that is what I would expect clients to do. Furthermore, disk controllers and disk subsystems are most likely going to buffer the data as it is read, and they very likely perform best if the data access is sequential. Lastly, I explicitly want to keep all of the data on the disk, and not buffer large chunks of it into RAM within my library. So, I settled on expressing my iterators as single pass, forward iterators. These are fairly restrictive in nature, but I think they will serve the purpose of reading data off of the file quite nicely.

    Regarding my choice to not buffer the data, let me pause for a minute and explain why I want to keep the data on the disk. First, in order to buffer the data from disk into RAM you have to read the data off of the disk one time to fill the buffer. So, that process automatically incurs one disk read. Therefore, if you only ever need to iterate over the data once, perhaps to load it into a more specialized data structure, buffering it first into an intermediate RAM storage will actually slow you down, and consume more RAM.

    The reason for this is that you would first iterate over the data stored on the disk and read it into an intermediate buffer. Then, you would let your client know the data is ready and they would iterate over your internal buffer to access the data. They might as well just read the data off the disk themselves! Finally, we are ready to implement the iterators themselves.

    To do this I rely on a very high quality open source library called Boost. Using it has proven to be a real time saver. One is the category defining the type of iterator you are creating. Here is the definition for the nodal geometry iterator: You can see that there are a few private functions here that actually do all of the work. You will also notice that I locally buffer the single piece of data associated with the current location in the iteration space inside the iterator.

    This is stored in the pData member function. I also locally store the current index. Here are the implementations of the functions just mentioned: First you can see that testing iterator equality is easy. All we do is just look to see if the two iterators are pointing to the same index.

    If they are, we define them as equal. This is important later on. Likewise, increment is easy to understand as well. We just increase the index by one, and then buffer the new data off of disk into our local storage. Finally, dereference is easy too. The only real work occurs in the readData function. Inside that function you will see the actual call to the CResRdNode function. We pass that function our current index and it populates an array of 6 doubles with data and returns the actual node number.

    After we have that, we simply parse out of that array of 6 doubles the coordinates and rotations, storing them in our local storage. A little more work, but not bad. These functions should return iterators that point to the beginning of our data set and to one past the end of our data set.

    What does that mean? What do two iterators need to have in common to be considered equal? They need to have the same index. You will also notice, that it does not have a second Boolean argument associated with it. I use that second argument to determine if I should immediately read data off of the disk when the iterator is constructed.

    For the begin iterator, I need to do that. In fact, no data for that node is defined on disk. I just need a sentinel iterator that is one past the iteration space.

    So, there you have it. Iterators are defined that implicitly walk over the rst file pulling data off as needed and locally buffering one piece of it. These iterators are standard conformant and thus can be used with any STL algorithm that accepts a single pass, read only, forward iterator.

    They are efficient in time and storage. There is, though, one last thing that would be nice. That is to provide a range object so that we can have our cake and eat it too.

    Like this: To do that we need a bit of template magic. Consider this template and type definition: There is a bit of machinery that is going on here, but the concept is simple. That is what this template will do. You just make a function like this: This function creates one of these special range types and passes in a pointer to our RST reader.

    That range object is compatible with the semantics of range based for loops, and therefore the compiler happily generates code for this construction. Now, after all of this work, the client of the RST reader library can open a result file, select something of interest, and start looping over the items in that category; all in three lines of code. There is no need to understand the nuances of the binlib functions. But best of all, there is no appreciable performance hit for this abstraction.

    Your mileage may vary… Share this:.

    The approach applies to solid and shell models. This article describes an approach with solid elements. Good quality modern graphics images of models, animations, results scoping, and other features of the Workbench Mechanical interface may be of interest to users. Users should review the Ansys v It contains information on reading an external model, as well as on rotating and translating the geometry that is imported. The External Model approach for model review is not an officially supported feature of the Ansys software, so users intended to use this facility must do their own quality control if this feature is employed.

    For simplicity, start by setting Units to those employed in the CDB file—the user must know this in advance: In the Workbench project page, drag an External Model component system into the Project Schematic.

    Then, drag an appropriate analysis system into the Project Schematic, such as the Static Structural. Now, close the window by clicking the X: Click the linked Model cell in the Static Structural system, right click, and choose Properties: In the Properties window that opens on the right, choose the Length Unit as in the CDB file, tweak the Tolerance Angle if needed to aid in fitting geometry faces to the mesh in a complex model, and indicate whether the analysis is 3D or 2D.

    To postprocess results on these components, ensure the check mark is set as in the figure above. Now, the External Model can be updated by clicking Setup, right-clicking, and choosing Update.

    Geometry will have been fitted to the mesh, and the Static Structural system can be opened to commence work: Right-click Model in the Static Structural system, and choose Edit: The Workbench Mechanical window is exposed. Elements from the CDB file are present, as is the geometry that was fitted to the elements. The materials used are not those of the CDB file—they are taken from the Engineering Data branch of the Static Structural system, and defaults will be assigned.

    Loads are not read from the CDB file, either. Note that the Static Structural system in the figure below is not ready to be solved—neither loads nor boundary conditions are present. At this point, a user could assign Engineering Data materials to geometric entities, place loads and boundary conditions on the model, and solve the FEA model.

    The model indicates that it is not ready to be solved because of the absence of loads and boundary conditions: Place an empty APDL Commands Object in the Static Structural environment. Its presence lets Workbench Mechanical assume loading exists, so that a user can load results from an RST file. Note that the. ERR error file for the model must exist there. If none exists, a dummy file with the correct job name can be created there, using the.

    ERR extension. The above window closes when the Open button is clicked. This is followed by a dialog box requesting that the user indicate the Units employed… the user must ensure that the correct choice is made, and click OK: With this done, a user can begin to request results below the Solution branch.

    ERR file must exist—create a blank jobname. Workbench Mechanical can now postprocess a model for which only an old RST file exists. RST files generated by Workbench Mechanical will not contain this mesh data, for size efficiency.

    As seen in the figure above, this approach can display degree of freedom data displacement in a structure. It can display stress and strain if they exist in the RST file. Probes cannot be created for reaction forces and forces across contacts since no such objects exist in the Outline—APDL Commands Objects would review such things.

    During model review, Construction Geometry can be used to create Paths and Surfaces to be used in postprocessing objects. In the figure below illustrates stress on a surface object.

    A Path can be created by various techniques, and results or linearized results shown on the path, for example: Results can also be presented as scoped onto selected geometry: An imported CDB file could contain contacts.

    The following figure shows two bodies in contact. A contact pair is created as a result of geometric proximity of parts—this does not reflect what contacts existed in the CDB file. Geometry can be fitted to the mesh, and Workbench Mechanical can receive the meshed model. An associated results file RST file for structures can be read into Workbench Mechanical, so that the tools of Workbench Mechanical can be used for model review.

    Generating a Report within Workbench Mechanical can produce extensive model information of potential interest, which would be tedious to generate manually. A factor can be applied to the movements, using values other than a default 1. If a negative factor of This might be used, for example, to find how to shape a structure so that it moves into a desired geometric shape after loading.

    Workbench Mechanical and FE Modeler could be used to find the geometry that fits that pre-deformed mesh. A more complex procedure could be used if large deflection effects were relevant for accuracy.

    This External Model approach permits the tools of Workbench Mechanical to be used to examine the results of old Ansys APDL models with the various advantages of the Workbench interface. Post Views: 7,

    To do this I rely on a very high quality open source library called Boost.

    Reading ANSYS Mechanical Result Files (.RST) from C/C++ (Part 1)

    Using it has proven to be a real time saver. One is the category defining the type of iterator you are creating. Here is the definition for the nodal geometry iterator: You can see that there are a few private functions here that actually do all of the work. You will also notice that I locally buffer the single piece of data associated with the current location in the iteration space inside the iterator. This is stored in the pData member function.

    I also locally store the current index. Here are the implementations of the functions just mentioned: First you can see that testing iterator equality is easy. All we do is just look to see if the two iterators are pointing to the same index. If they are, we define them as equal. This is important later on. Likewise, increment is easy to understand as well. We just increase the index by one, and then buffer the new data off of disk into our local storage.

    Finally, dereference is easy too.

    Separating Ansys DB Database File Contents from RST Results File Contents

    The only real work occurs in the readData function. Inside that function you will see the actual call to the CResRdNode function. We pass that function our current index and it populates an array of 6 doubles with data and returns the actual node number.

    After we have that, we simply parse out of that array of 6 doubles the coordinates and rotations, storing them in our local storage.

    A little more work, but not bad. These functions should return iterators that point to the beginning of our data set and to one past the end of our data set. What does that mean? What do two iterators need to have in common to be considered equal?

    They need to have the same index. You will also notice, that it does not have a second Boolean argument associated with it. I use that second argument to determine if I should immediately read data off of the disk when the iterator is constructed.

    For the begin iterator, I need to do that. In fact, no data for that node is defined on disk. I just need a sentinel iterator that is one past the iteration space. This is followed by a dialog box requesting that the user indicate the Units employed… the user must ensure that the correct choice is made, and click OK: With this done, a user can begin to request results below the Solution branch. ERR file must exist—create a blank jobname.

    Workbench Mechanical can now postprocess a model for which only an old RST file exists. RST files generated by Workbench Mechanical will not contain this mesh data, for size efficiency.

    Post-Processing APDL Models Inside Ansys Workbench V15.0

    As seen in the figure above, this approach can display degree of freedom data displacement in a structure. It can display stress and strain if they exist in the RST file. Probes cannot be created for reaction forces and forces across contacts since no such objects exist in the Outline—APDL Commands Objects would review such things. During model review, Construction Geometry can be used to create Paths and Surfaces to be used in postprocessing objects. In the figure below illustrates stress on a surface object.

    A Path can be created by various techniques, and results or linearized results shown on the path, for example: Results can also be presented as scoped onto selected geometry: An imported CDB file could contain contacts. The following figure shows two bodies in contact. A contact pair is created as a result of geometric proximity of parts—this does not reflect what contacts existed in the CDB file.

    Geometry can be fitted to the mesh, and Workbench Mechanical can receive the meshed model. An associated results file RST file for structures can be read into Workbench Mechanical, so that the tools of Workbench Mechanical can be used for model review.

    Generating a Report within Workbench Mechanical can produce extensive model information of potential interest, which would be tedious to generate manually. More on that in a minute.

    This is just so that everything is explicitly called out, and there is no guesswork when it comes to calling the routine. Now, consider this bit of code: First, I direct your attention to the big red circle.

    You also should notice the naming convention. I continue this pattern for all of the functions defined in the BinLib library. So, this function is nothing more than a wrapper around the corresponding binlib routine, but it is annotated and constrained to be interoperable with the C programming language. Now, there are a few more items that have to be straightened up.

    I direct your attention to the black arrow. This is stored in the variable ncFname. You can see that I compute this value using some intrinsics available within the compiler by searching for the C NULL character.

    Remember that all C strings are null terminated and the intent is to call this function from C and pass in a C string. Finally, after the call to the base function is made, the strings representing the JobName and Title must be converted back to a form compatible with C. For the jobname, that is a fairly straightforward process.


    thoughts on “Ansys rst file

    1. In my opinion you are mistaken. I suggest it to discuss. Write to me in PM, we will communicate.

    Leave a Reply

    Your email address will not be published. Required fields are marked *