CPRESS ODB incorrect number of values

[stinger4762]

I'm having trouble with the CPRESS field output from an Abaqus/Standard simulation.

I'm modelling a channel forming simulation of steel sheet of 2mm thickness with rigid tools as shown in the figure below:

I've partitioned the blank into two regions: the left region will be meshed more coarsely than the right. Both will be meshed with CPE8R elements.

Contact interactions are defined as surface-surface, with all rigid surfaces as the master surfaces.

The simulation runs successfully.

I want to plot the contact pressure along the top surface of the blank.

I defined a set that consists of the top surfaces of the blank within the blank's part properties.

From the ODB, I can define a path along the top surface of the blank using the 'edge list' type and the shortest distance along the top. I am then able to plot the field output 'CPRESS' along this path against either 'true distance' or 'x-values', and can then manually copy and paste the values into a spreadsheet.

However, I'd like to do this using Abaqus Python because it would save the time consuming 'copy-paste' method.

I'm using the attached script to read the 'COORD' and 'CPRESS' field outputs for the pre-defined node set.

The script successfully reads the 'COORD' field output for the nodeset. However, the same loop to read the 'CPRESS' field output produces 4 times as many values as from the same 'COORD' value. On further inspection, the script seems to run through the node set 4 times, with 4 different values for 'CPRESS' for each individual node. Having looked further at these values, there seems to be no pattern as to which 'pass-through' of the node set corresponds to the correct 'CPRESS' for that node. Probing the values from Abaqus CAE reveals that for some nodes, the first 'CPRESS' value corresponds to that from Abaqus CAE whereas for other nodes it is the 2nd, 3rd or 4th 'CPRESS' output that corresponds to this.

Is there something I am missing with the way that the 'CPRESS' variable is stored in the ODB file? I understand that it is a 'surface variable', however from the Abaqus Analysis Users Guide (Section 4.2.1) it says that it is a 'Mechanical analysis–nodal quantity'.

Any help would be greatly appreciated.

 

[Mustaine3]

As the manual says, CPRESS is a surface quantity. It is calculated to a nodal value (depending on the associated nodal area) to use it as nonhomogeneous output.

What you are seeing when looking into the .odb is the unaveraged value of CPRESS for each node. That means that you will have at least two values at corner nodes. As mentioned - it's unaveraged. The averaging is done in A/CAE.

I would recommend another approach for your task:

First you might change the way the path is created. Some years ago I've created a script, that automatically creates a path based on sets that the used defined in preprocessing. My script can handle paths that do not create a circle. So a nearly straight line like in your case is fine. My script will just sort the nodes depending on the distance to a start node. When this is done, the node numbers are used to create the path. When the path is created that way, you can use it in each frame, so no need to create the path again for other frames. 'let me know if you want to have that script.

When the path is created, you should activate the desired result frame, create the path plot and save the data of that plot into the xy data manger. Then you can automate that process and do it in all desired output frames. With Report->XY you can write all xy-data to a text file and do whatever you want with that.

 

[stinger4762]

I've had a look at the manual and I couldn't find any mention of the averaging algorithm - is this a generic method or does CAE do this on a model-by-model basis? We checked another, completely different model and it also repeated the node path 4 times for CPRESS.

So I've been able to define the path in CAE and extract information that way by exporting the data to an excel spreadsheet with Report->XY, but I'd be very interested to see your script too!

Thanks Mustaine!

 

[Mustaine3]

Averaging is a postprocessing task. It is possible to request certain results to be averaged by the solver, but that's not the default. Usually the solver writes unaveraged data to the odb and the postprocessor is doing the averaging.

The script should be attached.