up to now, I've applied the command EXTSEOUT (STIFFNESS MASS ASMBULK EXTID = 10 DMIGPCH) to get the matrices as a byproduct of the superelement reduction process.
This is ok for models of moderate size.
However, this approach seems not reasonable for rather large models (~1.000.000 nodes) as the intermediate files like *.DBALL are blown up to more than 16 GB and the computations take ages.
Since I'm not interested in the external superelement itself I'm wondering if there might be a simpler way to export the system matrices without extensive reduction computations.
Are you incorporating CMS in the superelement reduction? Or are you just trying to get the FULL (GSET) matrices? If the size of the DBALL is a main concern, you can add the keyword SCR=YES to the submittal and the Master/DBALL won't be written to.
Are there any MPC's, constraints, etc that you want incorporated into the reduced matrices?
The following alter will print, punch and op4 the GSET mass and stiffness matrix... you can comment out whichever format you don't need:
If you use the following MALTER instead of the one above, it will do the same for the ASET matrices... BUT this doesn't account for any CMS if doing a true SE reduction:
The MATGPR will print them to the f06- that will make for a huge file... the MATMOD results in the matrices being punched to the pch file as DMIG matrices... this is usually what is desired.
Also, if you add an "EXIT" command after the output commands, you can have the job 'stop' rather than continuing with the eigensolution, etc.
Also, those commands aren't going to work by themselves, but require the MALTER line to place them in the correct location of the solution sequence.
Unfortunately the *.pch file still exceeds 11GB as it's written in ASCII.
The *.op4 is binary but unfortunately all of the matrix entries (including also all zero entries) are written to the file leading to large file sizes, too.
Is it somehow possible to simply write the matrix information to a custom binary file in the following sparse format?
Did you try using the SPARSE op4 option? Instead of a positive IUNIT value, use a negative IUNIT and it should write sparse format. Use the DMAP Programmers Guide to see how the OUTPUT4 module operates. The resulting file size can actually be larger if there aren't many imbedded zeros.
For example, the following writes to Fortran unit 35:
output4 KAA,MAA,,,//0/35///15 $ non-sparse
output4 KAA,MAA,,,//0/-35///15 $ sparse
Also, the DIGITS entry on the OUTPUT4 statement can be changed for less precision… in the example above, it is using 15 but the default is 9... this would reduce the file size.
For example:
DIGITS = 9, then the format will be 1P,5E16.9
or if DIGITS = 15, then the format will be 1P,3E22.15
That is correct- I think the best option is to use the USET print to the f06 and read that output with a python script or some other tool. Check out the following two parameters and play around with the options.
PARAM,USETPRT,2
PARAM,USETSTR1,A
You will see a couple different formats printed to the f06, but here is one that is 'compact' and lists the grid id/DOF in ASET order.
U S E T D E F I N I T I O N T A B L E ( I N T E R N A L S E Q U E N C E , R O W S O R T )