System call from fortran . . .

Hi,

regarding the installation issues, the nightly builds should work again. We had some problems with the suitesparse package which is used for UMFPACK. The installation is described in the Downloads section and I just tested it on Ubunut 16.04 using these lines. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The large positive and negative numbers correspond to trignum1 and trignum2. I'm not sure what these mean, but they are large like this in most mesh files I've looked at.

The trignum's are used for meshing STL geometries. Therefore you don't have to worry about them when using CSG geometries.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Regarding the mesh file types:
Our standard file type is ".vol" or the compressed version ".vol.gz". These mesh files can also store geometry data when you mesh a CSG geometry (check the end of the file). This is useful if you want to curve the mesh when you solve a problem with NGSolve.
If you still want to have a mesh in "Neutral Format" you can generate that in one line: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

To check if cmake found any BLAS/LAPACK libraries you could use "ccmake". You have to install After configuring you call and press "t" for the advanced mode. Then you should find the entries

• BLAS_blas_LIBRARY
• LAPACK_lapack_LIBRARY

On my VM with Ubuntu 16.04 they are set to "/usr/lib/libblas.so" and "/usr/lib/liblapack.so". All the other BLAS/LAPACK entries are set to not found, but that should be fine.

Regards,
Christoph

Hi Tim,

Netgen and NGSolve built from source correctly for me on a fresh Ubuntu 17.04 VM using the default instructions on the "install from sources" page. The only change I made was to substitute the github repository in the git clone command (git clone git://git.code.sf.net/p/ngsolve/git ngsolve-src changed to git clone github.com/NGSolve/ngsolve.git ). I didn't do anything with cmake or ccmake.

I think the problem you were having building from source was an out of memory error. This causes the compiler to error out and, as I recall, the cmake script continues on and generates some spurious error messages about LAPACK and BLAS so the memory error may go unnoticed. The memory usage hits a peak of about 9GB about 45% into the ngsolve install.

I think Christoph's post explains the issue with the nightly build and several other things.

Best,
Dow

Dow:

On my well-used, much updated (since 10.04 LTS) vm, there is no progress beyond netgen. It is convinced it cannot/did not find laback and blas. (I will have a look at Christoph's input in more detail as well.)

On my leaner, less traveled vm, the reinstall - starting by completely blowing away ngsuite - was successful. 'It' found lapack and blas, as before. I watched during the (long!) make process, and indeed the memory usage exceeded 9 Gb during the processing of hpcurlhofe_prism.cpp.o. And indeed, the vm's 8 Gb of ram was not enough. But I have another 8 Gb of swap, so all went well. At least nqsuite/ngsolve-install/bin contains:

netgen, ngs, ngscxx, ngsld and ngsolve.tcl.

I don't know if that is the complete set of files expected.

Thanks, Tim

PS:

NOTE: Along the 'make' way, there were many (dozens?) of warnings (I assume.), such as:
[ 4%] Building CXX object ngstd/CMakeFiles/ngstd.dir/table.cpp.o
In file included from /home/tscale/ngsuite/ngsolve-src/include/../comp/comp.hpp:74:0,
from /home/tscale/ngsuite/ngsolve-src/include/comp.hpp:1,
from /home/tscale/ngsuite/ngsolve-src/multigrid/multigrid.hpp:15,
from /home/tscale/ngsuite/ngsolve-src/multigrid/prolongation.cpp:11:
/home/tscale/ngsuite/ngsolve-src/include/../comp/periodic.hpp: In member function ‘virtual void ngcomp::PeriodicFESpace::GetVertexDofNrs(int, ngstd::Array<int>&) const’:
/home/tscale/ngsuite/ngsolve-src/include/../comp/periodic.hpp:50:40: warning: ‘virtual void ngcomp::FESpace::GetVertexDofNrs(int, ngstd::Array<int>&) const’ is deprecated: Use GetDofNrs(NODE_TYPE(NT_VERTEX,nr) instead [-Wdeprecated-declarations]
{ space->GetVertexDofNrs(vnr, dnums); }
^

Hi Tim,
Yes it sounds like the install completed correctly on the newer VM. I see the same in ngsuite/ngsolve-install/bin. I wouldn't worry about the warnings emitted when compiling NGSolve. I think they are all referencing method calls that have been deprecated in the last month or two. They are primarily of concern to the core team.

Best,
Dow

Testing the netgen/ngsolve install discussed in my previous post:

I can get from a .geo file to a .vol file:
netgen -batchmode -geofile=/home/tscale/ngsuite/ngsolve-install/share/netgen/cube.geo -fine -meshfile=out.vol

I can get from a .geo file to a .mesh (Neutral) file, which looks good - no strange numbers:
netgen -batchmode -geofile=/home/tscale/ngsuite/ngsolve-install/share/netgen/cube.geo -fine -meshfile=out.mesh -meshfiletype="Neutral Format"

When I run the netgen-generated Neutral file (out.mesh):
netgen -batchmode -inputmeshfile=out.mesh -fine -meshfile=out_out.mesh -meshfiletype="Neutral Format"

netgen knows it is a neutral file, but puts out:
NETGEN-6.2-dev
Developed by Joachim Schoeberl at
2010-xxxx Vienna University of Technology
2006-2010 RWTH Aachen University
1996-2006 Johannes Kepler University Linz
optfile ./ng.opt does not exist - using default values
togl-version : 2
no OpenGL
import mesh from out.mesh
Read User File
Reading Neutral Format
has no facedecoding: fd.size = 1, ind = 2
has no facedecoding: fd.size = 1, ind = 2
has no facedecoding: fd.size = 1, ind = 2

many more lines . . . that look the same.

21 Points, 28 Elements.
Export mesh to file out_out.mesh.... Please Wait!
Export mesh to file out_out.mesh, format is Neutral Format
write neutral, new
Export mesh to file .... DONE!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The resulting file has the same node list and element list as the input file; but the face list, which has the same node numbers as the input file, has several interesting entries in the first column.
~~~~~~~~~~~~~~~~~~~~~~~~
Face section of out_out.mesh:
36
1 1 9 18
1 4 17 9
1 7 12 17
1 3 18 12
1 9 17 18
1 12 18 17
858993459 1 20 9
858993459 4 9 19
858993459 6 19 13
858993459 2 13 20
858993459 9 20 13
858993459 9 13 19
3 8 10 11
3 7 17 10
3 10 17 19
3 6 11 19
3 4 19 17
3 10 19 11
1752393069 8 16 10
1752393069 7 10 12
1752393069 3 12 14
1752393069 5 14 16
1752393069 10 16 14
1752393069 10 14 12
-1649656920 8 11 16
-1649656920 6 13 11
-1649656920 2 15 13
-1649656920 5 16 15
-1649656920 11 13 16
-1649656920 13 15 16
16400 5 15 14
16400 3 14 18
16400 14 15 18
16400 2 20 15
16400 1 18 20
16400 15 20 18

Christoph:

Thank you for the information.

I decided to install from an installer, per your post. It worked nicely. At least netgen works the same as the version I installed from source earlier today, on a different vm.

Both installed versions of netgen behave the same:
(.mesh ~ neutral fomat)

I can input .geo files and generate meshes (.vol and .mesh files) in batch mode. When I input the .vol file created from the .geo file, and ask for a .mesh outfile, I get 'translated' mesh info. When I input the .mesh file created from the .geo file, I get a "corrupt file" (as noted in an earlier post, wrt testing the installation on the other vm).

I used netgen in 2013, with both .vol and .mesh files. I preferred the latter, as they are closer to the other mesh file formats I use.

But either format will do: BUT my task it to create volume meshes from surface meshes. These surface meshes are of moderate size (10^5 faces).

I am not sure how netgen is usually used, but I remember using it to do this task (albeit on surfaces with O(10^4)) faces; and hope to be able to do so again.

Regards,
Tim