forums.silverfrost.com

[jjgermis]

We use the (FEM) matrix renumbering scheme found at:
1.) algorithm 509 and
2.) algorithm 508

The subroutine uses assumed size arrays. In debug and release mode the results are correct. When using checkmate an array out of bound error appears. What is the reason for this?

[JohnCampbell]

Try the following change to your code:
DIMENSION NDSTK(NR,*), NDEG(*), IOLD(*)

This should stop bound checking for these arrays.
Alternatively, you could try and find what size has been allocated for these arrays in the calling routine.

This looks to be very old re-ordering code. You could try googling Marc Hoit or Scott Sloan for better algorithms, at least they were in the mid 80's.

John

[davidb]

This line

[jjgermis]

Thanks! Problem fixed. Continuing the checking resulted in a few type errors in the "implicit" part of the renumbering! It is the first time I use Checkmate and find it quite usefull!

John: Thanks for the tipp on the other renumbering schemes. In fact I have a working version of the Sloan code. At the moment I am re-arranging our existing code using a bit "modern" Fortran. As soon as the test-vector tests past, I would like to implement the Sloan code.

[JohnCampbell]

I have implemented both the Hoit and Sloan algorithms plus my own approach. Combining all 3 gives a fairly robust profile minimisation.
My approach is to test 3 node order lists by sorting all active nodes using:
x + .01y + .01z
y + .01x + .01z
z + .01x + .01y
It is surprising how frequently this simple approach produces the best solution, without any consideration of the tree structure of the connectivity.

John

[jjgermis]

John, this is perhaps not on the topic. However, responding with Sloan so quickly means that you are familiar with this stuff! Anyway, the code I mentioned might be old-style Fortran. It compares good with the Sloan version.

1.) Test data by Everstine
2.) Sloan paper with code

[jjgermis]

One last comment on Checkmate: I have been trying for days now to get the FEM (skyline) solver to work after some maintenance. Once I got the checkmakte to get to to solver part, the problem was fixed in a matter of seconds! That is another point to add to my list why I like FTN95

[JohnCampbell]

The code you have looks like a variant of the RCM approach.
If so then Sloan should do better in most cases and much better in a few.
Sloan and Hoit consider both tree level and front size bias for their ordering approach, while RCM is basically limited to tree structure assessment.
I did a lot of work on this in mid 80's, trying to understand how these methods fail.
Recently I have been converting to Fortran 95, trying to produce code which is more conforming to the standard, especially in terms of memory management.
I have tried some variation to the Sloan/Hoit approach, by introducing a concept of member length into the tree level attribute. It works for a few examples but in general was not effective. The combination of Sloan, Hoit and sort is as good as I've been able to achieve.
The Hoit algorithm has a dual node connectivity and element connectivity data structure, retaining more of the element attribute in the algorithm. This has an advantage for some problems. My variant of the Hoit algorithm includes a tree level attribute, with a combined front size and tree level weightings in the approach, similar to Sloan.
I have a number of examples where both Sloan and Hoit do not work well. My directional sort approach addresses a number of these types, but there remain a number of examples with apparently poor ordering. My Everstine data sets are just connectivity data and now they look so small.
Some are characterised by a multiple ring structure, but others have no apparent type of tree structure to distinguish their unsuitability to the Sloan or Hoit approach.
My other recent project has been to parallelise my skyline solver to improve performance. It has not been a successful project to date. The solvers in the main commercial FE codes appear to be much faster and I wonder if the skyline/profile direct solver is an obsolete approach. It�s difficult to get a reliable comparison.
There are a number of others on this forum who have worked in this area.

Good luck

[jjgermis]

Hi John, thanks for your reply. This sort of motivates me to get deeper into the stuff. Our code is definitely not up to date. I only inherat the code and recently did a lot of reading on the different methods (renumbering, sparse matrices, direct solvers, etc.). Luckily I do not have to program the stuff from scratch. Since we use it for rotating electrical machines the movement is the important part. For this we use the approach explained in:

1.) A.A. RAZEK, J.L. COULOMB, M. FELIACHI, and J.C. SABONNADIERE
The calculation of electromagnetic torque in saturated electric machines within combined numerical and analytical solutions of the field equations,
Trans. I.E.E.E., Vol. MAG 17, pp. 3250-3252, 1981.

2.) A.A. RAZEK, J.C. COULOMB, M. FELIACHI and J.C. SABONNADIERE
Conception of an air-gap element for dynamic analysis of the electromagnetic field in electrical machines,
Trans. I.E.E.E., Vol. MAG 18, pp. 655-659, 1982.

There is no mesh in the air gap. Recently a student cleaned up the code and did a lot of improvements (thesis). We also started using an open source mesh. However, I found no 2D mesh generator written in Fortran. The one I have is very primitive and one actually needs to "program" the mesh.