forums.silverfrost.com

[jjgermis]

Hi John,

thanks for your offer! I will come back to that. For the moment my roadmap is only to clean up and document what we have. After that I would really like to improve the code - in fact I already have some ideas where one can improve.

Our solver uses the ACTCOL from Zienkewich. I actually bought a German translation of the third edition to get hold of the Fortran IV code in chapter 24.

In the fifth edition the explanation and example of in the direct solver part is still the same (p. 610). However, I think that the profile storage has change a little bit. In the new version the diagonal elements are stored first and then the rest of the elements in each column. In our version each column is stored as it is, i.e. the diagonal terms are spread through the array.

I have also updated my eps format to plot the elements in the lower triangle blue and the ones in the upper triangle green

[jjgermis]

Hi John,

one further remark: initially I thought I can easily just replace GPS with Sloan. The adjacency list is formed in row-major - as required by GPS. As usual is everything catastrophe

Anyway, here is an example with the colors for lower and upper triangle. For the profile solver one actually needs to calculate the column heights. In our program practically the row widths are determined - works due to symmetry. However, is sometimes confusing if you look for something specific and find the opposite.

[JohnCampbell]

The data structures you choose for the re-ordering algorithm are very important for the efficiency of the algorithm. The secret to efficiency is to have a number of node and element status arrays, so you don't have to calculate an updated status in inner loops.

My algorithm starts with 5 basic vectors.
Based on the element definitions you can readily generate:
IELEM(num_elements+1) ! which is the pointer to the first node in a list vector of all nodes connected to each element.
LNODE(*) is this list of nodes connected to each element.
Based on these two vectors there is a complimentary list structure for nodes:
INODE(num_nodes+1) ! which is the pointer to the first element in a list of all elements connected to each node.
LELEM(*) is this list of elements connected to each node.
NFREE(num_nodes) ! which is the number of freedoms(equations) associated with each node.
The size of LNODE and LELEM are the same.
You can filter these lists to remove:
- all nodes with no freedoms
- all elements which are not connected to multiple free nodes.
This reduces the size of the problem, although you need to keep 2 vectors that point to the original node and element numbers if you compress the numbering to only those active nodes and elements. ( that�s 7 vectors)
You also need further vectors for:
- the node weightings
- the element weightings
- the best node order
- the next possible node order
- the next possible element order
- status vectors for each node and element as to how they have progressed through the front.

That�s 14 vectors and I use a few extra as I go along. The good thing is these are all 4-byte vectors and the storage required is insignificant compared to the storage required for the final equation matrix.
The use of ALLOCATE works very well with this, as all vectors can be sized before you start.
(The size of LNODE can be scanned from the element connectivity info before you start, using IELEM to first store the count of nodes as you proceed, noting active nodes and elements. It can be all Fortran standard conforming, removing all the memory management tricks of F77)

After 30 years, I'm still changing the code from time to time, most recently to be standard conforming F95. Your graphics has got me to thinking that I should place it in a %gr window and draw the order for each iteration as I go through the list of possible starting nodes. It might identify different ways of defining the node and element weights.
Generating the starting node list is the other half of this very interesting auto-ordering problem !

John

[jjgermis]

Hi John,

thanks for your ideas. This is very exciting! This motivates me to finalize my "cleaning and document the code" project. Once everthing is working "again" I am going to try all this out. With the working copy I can test the differences between changes.

I liked you comment on codes changes Our air gap code I change all the time - one always find new possibilties in the programming language.

What is your experience on not programming code in colum-major. For example: Fortran is a column-major language. The GPS code is programmed in a rather row-major. For small programms one will note notice the difference. However, for large meshes this could perhaps be an issue. However, I do not know wheter this is the case with current computers - and reprogramming the code just to check is to much effort. Do you have any experiene on this?

[JohnCampbell]

You asked:

[jjgermis]

Hi John,

thanks for your excellent comments and ideas!

I have taken a look at our code and your comment below applies. In many cases the code and the documentation is the other way arround. This is really very confusing and something ons should take care of. The stiffness matrix for our air gap element is such an example. Since this is a dense matrix your suggestion to make use of array syntax on the inner loop might improve the performance.

[jalih]

[jjgermis]

Hi John,

how is your visualization with %gr coming on? Unfortunately I am not that fit in Clearwin. Since I use eps in my documents I prefer to do all figures in pure eps rather than converting it. However, I think it should be easy to do it in Clearwin.

Coming back to the numbering: For the same example I only changed the node numbering manually. In this small example one can clearly see that the solution is independent of the node numbering. The profile for the second numbering scheme is larger than the first one. For problems with many nodes this is, as you know, critical for a direct solver - compact storage scheme by Alan Jennings.

[JohnCampbell]

Jalih,
You said: