PrePoMax testing feedback - suggestions

Feature Requests
1

Hi there,

At long last I had some quality time to get my teeth onto PrePoMax (PMX).
I’m lost for words on how good a job you’ve done, impressive!
I was an early adopter, at the end of the 90s, of the 1st Abaqus/CAE beta version. I’ve missed very little from that tool when working with PMX.
You’ve done better the keywords editor, speed, annotations… excellent improvements on workflow’s speed.

Very pleased to see you haven’t made the Gmsh tet mesher the default, I tested in the past for a start-up and won’t do the job on real CAD modelling. What you’ve done seems way better as is, for tet meshing.

As a result from the great testing success, I only have some minor suggestions, mainly from the side of basic FEA building blocks and easier workflows, aimed at FEA assemblies, which are what most (complex) production FEA is about.

1.- Import part names into the tree from STEP assemblies.

This would then link the CAD assembly naming convention on parts with the FEA models. The part names do make it into the STEP files fine.
Example:

image
image1920×1802 296 KB

2.- Implement 2-node springs:

Even if CCX doesn’t handle them on all DoF (from what I’ve seen, see thread here), so that PMX becomes a general pre-FEA for any solver. Writing a crude python translator by users for their needs, they can mostly do, usual part of being an analyst, coding tools.
These are building blocks in general structural FEA:
CBUSH in Nastran & (cartesian + rotation) connectors in Abaqus. They allow for 6 K values to link both nodes, which then allow to form any type of joint with 2 ‘soft’ couplings using the ends of the spring as single reference_nodes on each.
I think you have this under entry #17 in your list.
image

3.- Both couplings types:

Rigid (RBE2 or kinematic) & ‘soft’ (RBE3 & distributing).
Again, these are part of basic building blocks on any serious FEA solver. Allow for correct loading and constraining of local areas on a per DoF basis, arriving to realistic model results.
Rigids should be avoided at all costs, if possible.
Pairs of ‘Soft’ couplings + a 2-node spring will allow to build any assembly connection/joint you like for any linear FEA assembly. They allow for realistic compliance without compromising on artificial ‘rigids’. Nothing is infinitely stiff in real structures.
I think you have this under entry #39 in your list.
image

It’s basically your (already in place) rigid body panel, but with different commands on the output, same ingredients. Then we can hand edit later in keywords editor and/or input deck if needed, but crucial to have them in the UI to build/understand/explain complex assemblies.

4.- Allow for node sets with RP points:

RPs are typically used in couplings and/or springs, and being able to use them via node set names allows for powerful templating on steps, constraints and loads (force, moments) across different setups.

Other than that for now, a belter of a tool you’ve built. I’d love to see it more as a generic fast/powerful pre-FEA UI, rather than fitting so much to Calculix limitations. I’m using it for code_aster solving, and so far, no probs from your side. The lack of 2.- & 3.- above I can do via a *user_element in editor → python → code_aster; but it’d be amazing if they were in the UI.

Cheers, and thanks!
Jesus

1 Like
2

Thank you!

I am currently using Netgen to open the geometry, and I think that part names are not read while the geometry is loaded (I might be wrong). However, the decision not to use the part names comes from regeneration. Regeneration can regenerate the model from another .step file, but if the names of the parts in the .step assembly change, some regeneration commands will fail. However, I might look into that since I would also like to have named parts in the assembly.

There were other requests for this feature so that I might give it a higher priority.

True, rigid connections are not the best connection type. The distributing connection is already on the request list.

If I understand correctly, there is a need to create a node set shown in the model tree containing a reference point. Is it enough to contain a single RP?

1 Like
3

Thanks, yes ref 4.- : a single node set per RP would be perfect for templating and general outputs to other solvers via set names.
Just one node on each, I don’t understand the logic behind CCX using a dummy 2nd node on RPs with DoF 1,2,3, makes no sense to me in FEA. One node on RPs handles 6 DoF in all codes I know.