How about adding openradioss support

I was thinking of trying to write a translator from PrePromax/Calculix to openradioss. But maybe it would be something that could be done as part of the program.
And thanks for putting this great program together.
Laurence

Most likely, It would be too hard to make sense, CalculiX and OpenRadioss are completely different solvers and support for the remaining CalculiX features is a priority in PrePoMax. Also, PrePoMax is designed specifically for CalculiX so its UI would have to be changed or some features left unsupported for export to OpenRadioss. If you need a preprocessor for OpenRadioss, FreeCAD might be a better idea. Its FEM module is more general and supports multiple solvers. There was even a discussion about this on the FreeCAD forum when OpenRadioss was released. Salome could be another option.

Maybe an external translator would be doable. It should operate on the .inp files that can be exported from PrePoMax. This way input files also from other preprocessors (like GraphiX utilized by many CalculiX users) would work. Still, the differences between the solvers might be too large and it would be probably way easier to create a preprocessor specifically for OpenRadioss so that you can import the mesh (meshing can be done in Gmsh or other software like that) and set everything for OpenRadioss analysis.

1 Like

Thanks for getting back to me. I thought as much :slight_smile: At one point I did manage to get Abaqus models into Dyna in quite a useful manner. Will have a look at the Freecad option - I use that for Openfoam pre…

welsim is working on openradioss and su2 support. it’s not ready yet though.

Didn’t know about this new software. Did some of you use it?

Working at export capabilities seems more feasible instead of mixing both solver inside one interfaces. It’s limited to implicit solver due to meshing element type generates by PrePoMax.

Currently only GMSH which capable and supported officially to export an openRadioss format, some notify on mesh type specially for explicit solver is required to be fully quadrilateral or hexahedral element.

Actually, explicit dynamics step is also supported in PrePoMax 1.4.0 (dev version for now) but CalculiX’s capabilities in terms of this type of analyses are highly limited.

1 Like

That’s interesting - should make writing a translator loads easier though… At the least the deck will have the right stuff in it.

I’m not sure about it. In CalculiX, it differs from the implicit dynamic step with just a single word in the dynamic step keyword. The remaining syntax is the same. And even mass scaling is defined in a rather unusual way - by specifying the desired increment size as if it was the minimum increment size in an implicit analysis. The general syntax for steps, loads, BCs, interactions, constrains, outputs and others would be a big problem here.

1 Like

What like Abaqus explicit does when you ask it to mass scale around the model so it runs at a given timestep?? I think that if you can get a mesh and BC’s across you can do the rest with a text editor.

the developer notify, It’s related to mesh type, a common good or reliable mesh for implicit solver can be bad for explicit solver due to ratio of element mass and stiffness distribution in whole models.

This is still questioning to myself personally, how much is affect to the reliability of results.

In Abaqus, this functionality is really advanced. You can apply fixed or variable mass scaling, define it in terms of scale factor or desired increment, apply locally or globally and so on. There’s a whole window for that.

Its not that tough to find this stuff out. (I’m currently writing a getting started course on this for NAFEMS)

openRadioss has implicit solver, so it’s good starting point to implemented for compatibility reasons. Explicit solver can be supported later by the exporter.

I will add my opinion without knowing the structure of the openRadioss. While developing PrePoMax, I am constantly thinking of supporting other solvers (code_aster) while developing the user interface. Some features are defined in the same way for all solvers, while others differ quite a lot. In such cases, an adapted user interface must be added not to confuse the user. This takes a lot of work. First studying the new solver, studying its special cases and then adding the support itself.

So if we would support only the basic features, it would be easier to support them from PrePoMax than creating a converter from .inp input file to the openRadioss file. Additionally, a lot of work would also fall to support reading the result files.

So in this phase of development, there are still features important for CalculiX simulations missing and they will have priority.

1 Like

The reason I asked was that I thought it would be easier to do from Prepromax than as a stand alone translator. Anything that did mesh and basic BC’s would be great. Possibly sets. Beyond that text editing would get you there. Thanks.

Adding PrePoMax capabilities in exporting mesh and group set as UNV can be useful, at least more easy since group of element, face and nodes has been defined initially.

It’s more general and basic approach for bridging files between CalculiX/Abaqus and other solver e.g openRadioss with Gmsh or Hypermesh and LS-Dyna with LS-Prepost. Also, code_aster with Salome-Meca.

An update from Altair:
OpenRadioss’ *.inp to *.rad converter

LinkedIn Post 1

LinkedIn Post 2

2 Likes