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.

4

Hi again, I forgot to ask something I noticed during my testing.

When defining a TIED contact via selection of surfaces in the display area, the output in the input deck prepends surface and elem_set names involved with some very long tags, all the same.
Since the Tie name in tree must be unique, and you nicely append _Slave & _Master to each side of the pair, why do we need these dummy long prepends in names in input deck?

Not a significant issue, but some solvers have a limit on name lengths. Thanks.

image
image1241×699 110 KB

5

That name is not the Tie connection name. It is the name of the Surface or element faces component created by the program when you define the Tie connection by selecting the entity face. When you use entities to define boundary conditions and other operations, the program automatically creates nodes, elements or related element faces, Surface and other components of the selected entity, and uses these component names in subsequent definitions.

6

Entirely my point, and those node, elem, surface names (off a tie constraint name) do not need to have “Internal_Selection-1_” pre-pending all, since they are already unique off the (unique) Tie name.

See here, if you removed the long ‘prepends’ it’d still all work right? nsets & elsets can have same names in a deck, then all else would be fine.
As I said, not important, but seems unnecessary.

image
image626×796 12.9 KB