Resource Menu


posted by julien at Aug 1, 2006 3:44 PM
Quote
Dear Bjorn,

First of all, most of the problems that you outline have been solved in the last development version of SPIS. However, the release and the pre-release (pre-distribution of the candidate release) have been delayed by ESA to the end of August, after the holidays.

To answer to your technical questions:

1) Various mesh size depending on the OS:

On the current public version of SPIS (3.1.01) the loaded mesh structure is not really saved but re-mesh every time you process the pre-processing phase. The Delaunay’s algorithm used in Gmsh, the mesher, can sensitive to the rounding and truncating errors.

Depending on the OS (Linux and Windows), the rounding and truncating error are not the same and meshes can different.

This default has been fixed since in SPIS. The last development versions of SPIS save and reload the whole mesh, which is then OS independent.

An additional point, in several cases and if the refinement criterion is sever, i.e if you have very large variation of characteristic mesh size in the grid, you can be close to a threshold for the mesher that can generate strongly different mesh depending on these rounding errors.

This in large part solved in the last development versions of SPIS, where a new and high performance library for the mesh, called LightMesh, has been introduced.

On the basis of the current public version (3.1.01), I recommend:

a) Work, as possible, always on the same OS.

b) Play on the local resolution (especially, on the node where the resolution is the highest) to obtained a “reasonable” and constant mesh…

2) Memory cost and limitation:

The second question gathers two problems:

a ) The version 3.1.01 is still based on the old mesh structure and is in practice limited to about 150 000 or 200 000 tetrahedrons by Gb of RAM. With this version, unfortunately we cannot do better. On a 2GB computer, a mesh of 350 000 is practically reachable.

This has been solved in the last development versions of SPIS, with LightMesh, which is able to load more than 1 million of tetrahedrons by Gb of RAM.

The extension of the Memory Stack of the JVM (the –Xmx flag) is exactly what you must do to load a larger grid.

b) The second limitation at 1.44 Gb is due to standard versions of Windows (used at ESA for common desktops and workstations) that limits the memory attributed to a single job (i.e the JVM) less than 2GB. A second limit appears at 4Gb max for the whole system…

If you wish overtake this limit use Pro/Server version of Windows or… Linux

We are currently testing the new version of SPIS on a Linux station (quadri-Opteron with 16Gb of RAM). Results (good) are pending…

Please feel free to send questions and comments on this forum, Best regards,

Julien for the SPIS core team.

posted by Bjarne Andersson at Jul 24, 2006 10:13 AM
Quote
Dear Who It May Concern,

I have discovered a funny behaviour with SPIS (version 3.1.01), which have lead to a problem for me.

I have been running the very same simulation using Windows XP and Linux, this because I was facing an out of memory problem in Windows. While performing the 3D Mesh, the simulation in Linux gives 4383 nodes and 22851 elements, but in Windows it gives 55334 nodes and 348450 elements! Could you please explain to me why the numbers of nodes and element are more than 10 times as many in Windows, and could you also explain how to reduce them to the same level as in Linux (if possible)? Worth mention is that other "smaller' simulations works fine in Windows.

As mentioned above, the simulation I am trying to run leads to an out of memory problem in Windows, which makes SPIS crash. I believe that my computer (3.2 GHz, 2GB RAM, 60GB free memory) should be able to handle most type of simulations, and I have increase the memory stack size in the jython.bat file to a present value of –Xmx990m according to the suggestions in the readme.txt file and elsewhere in this forum (I have even tried to increase it even higher but above –Xmx1400m SPIS UI starts to act funny).

I would be very grateful if you help me out with this one.

Best regards,

Bjarne