Is there an error in the Harwell-Boeing Output for a CMS superelement .sub file?
Is it possible that ANSYS 9.0 does not write out the HB correctly? Or in a
format that does fully not correspond to the guide I have (TR/PA/92/86)?

The SELIST command ANSYS shows that the .sub file for my test problem has
324x324 matrices (24 nodal DOF and 300 modes). I read the matrices from
the SElist output (lower precision obviously) into Matlab as a check. Next
I read in the HB file data with no big problems. The check between the
two failed, however, so I took a closer look at the HBmat ASCII file.

The HBMAT command in this case wrote out a fully populated HB format file
(324x324 values) as if there are no zeroes and the matrix is non-symmetric.
I was expecting the document form for a symmetric matrix given MXTYPE=RSA,
that is, only the lower triangle including the diagonal with zeros
eliminated. BUT this is no big deal, particularly if ANSYS consistently
does the same thing each time.

When I examined the data it became clear that the COLPTR array from the
file would not re-construct the matrix correctly. The column pointer index
varied by 325 instead of 324 for the fully populated rows so the matrix
reconstruction loop was overwriting entries. I created a new COLPTR array
that fit the data and the subsequent matrix matched (to precision limits)
the SElist data.

My question for you is: Does ANSYS always write out a fully populated
matrix for the HBmat? If so, my current translation procedure is
sufficient & needs no change except perhaps to add provision for
transposition of a non-symmetric matrix. And in that case, would MXTYPE
change to indicate asymmetry, RUA, for example?

Also, can you verify that the last table in the SElist file before the
matrix data (Global DOF) is the correct DOF assignment for matrices?

The test model is a simple plate with the corner nodes as MDOF and 300
modes generated for CMS.


Yes, there is an error, Defect54655, corrected in ANSYS 11.0. As you describe we
are off by 1 for each column in writing the COLPTR values.

Our experience so far is that users have been using the HBMAT command to mainly
dump the contents of a .FULL file, so it's not surprising that you have found one issue
that is not entirely clear and a second issue which is a bug.

To answer your question, yes, the HBMAT command writes a full matrix when dumping the .SUB file.
Please note that this is only true when dumping the .SUB file. When using the HBMATcommand to
dump the .FULL file, it will dump only the lower triangular matrix if the matrix is symmetric.

The .SUB file contains the full matrix regardless of whether the matrix is symmetric or nonsymmetric.
The HBMAT command simply dumps what is on the file. So for the .SUB file it dumps the full matrix regardless
of whether the matrix is symmetric or nonsymmetric and regardless of whether the matrix coefficients are
zero or non-zero. For the .FULL file, only non-zeros are written on the file and only the lower triangular part
of the matrix is written if the matrix is symmetric so we only dump those values.

There is a flag in the .SUB file header that tells anyone reading the .SUB file whether or not the matrix is
symmetric or nonsymmetric. This flag is used by the HBMAT command logic to write out an RSA/RUA mxtype
value, so to answer your question, yes the correct RUA mxtype value will be written out in the .matrix file if the
matrix is truly nonsymmetric.

It is confusing that the full matrix is written out regardless of whether any of the values are zero
and regardless of whether the matrix is symmetric or nonsymmetric. We will make this correction in the HBMAT
command documentation for our upcoming v11.0 release.





Show Form
No comments yet. Be the first to add a comment!