forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Using Makefile
Goto page 1, 2  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
narahari



Joined: 02 May 2018
Posts: 3

PostPosted: Sat Sep 05, 2020 7:27 am    Post subject: Using Makefile Reply with quote

I am a newbie to use of Silverfrost ( I was coding on IBM mainframe and later RS6000 platforms before retirement) so this question may have been addressed before apologies for that .
I would like to use an Open domain CFD code called ADflow (https://github.com/mdolab/adflow) which is a part of MDO work. However, I cant figure out how the application can be built on PLATO/SILVERFROST platform . Makefile is provided but I guess that is for Linux environment, unfortunately I am on Windows10 !!
Any suggestions / pointers or even a simple demo Makefile will be of great help
Thanks in advance
Narahari
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Sat Sep 05, 2020 8:58 am    Post subject: Reply with quote

Considering the nature of the huge package, its application area (solving turbulent flow using Reynolds averaged Navier-Stokes equations), and prerequisites (MPI, PetSC), I do no think that it is reasonable to try a serial version build effort using Silverfrost Fortran on Windows.

Even if you managed to build successfully, I think that the execution times would be very large on a consumer PC.

That is a package for a supercomputer, or at least a cluster with scores of CPUs, and a team of programmers with project supervisors.

Perhaps John Silver can add his comments, since he works in aerospace.
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Sat Sep 05, 2020 8:41 pm    Post subject: Reply with quote

Yea, FTN95 offers a lot of thing other compilers can not do. But other Fortran compilers also have something FTN95 can not yet do or a bit losing to others.

The Silverfrost has to figure out how to synchronize their compiler with other Fortran compilers in these two-three respects
1) add OpenMP. All other Fortran compilers have added this lately
2) minor, but important probably: make sure that MAKE works without changes with MAKE from other Fortran compilers like gFortran and IVF
3) this is really important for publicity: find specific places in Fortran sources from Polyhedron tests which sometimes slow down their codes. There might be just 1-2 of them but they influence many things

May be also good to add support for reading/writing HDF5 files as the read/write speeds there 10 times faster than unformatted read/write. Fortran FTN95 READF/WRITEF also fast but they are non-standard and HDF5 still beats them probably by factor of 2. I see other Fortran compilers started to add HDF5. MATLAB also has HDF5 support. When parallel HDF5 will be ready, the speed difference will be 20x.
Mecej4 cited here some opinion about drawbacks of HDF5, the claim was that some users tend to abandon HDF5. After using HDF5 for a year i find that this format is VERY VERY useful. No any problems or objections at all. It is literally crazy fast. I do not understand how it is saving 20 GB files on supercomputers in a blink of an eye. And colleagues report no single case of files being corrupt in 15 years. And in our case nobody cares about theoretical probability of file being corrupt as main use of them is for intermediate storage anyway. If some HDF5 file will be corrupt in the next 100 years our grand-grand-grand-children will re-run the entire simulation in one day (on today computers) or in one second (100 years from now).

Of course MAKE is possible to substitute with just usual batch compilation in Command Prompt mode. I do not know what Python is specifically doing with this CFD code, as well as small part in C.

As to hardware, having many cores in the home PC is not a problem anymore. The 12-16 core PCs are mainstream, processor itself costs $500-700. The 32-cores processor is just $1000 more and 64 cores is $3000 more plus $500 more costs server motherboard.
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Sun Sep 06, 2020 2:26 am    Post subject: Reply with quote

The ADflow documentation contains references to running examples on the NASA Pleiades Supercomputer. Here are some related specs:

Manufacturer: SGI/HPE
158 racks (11,207 nodes)
7.09 Pflop/s peak cluster
5.95 Pflop/s LINPACK rating (#32 on November 2019 TOP500 list)
175 Tflop/s HPCG rating (#17 on November 2019 HPCG list)
Total CPU cores: 241,324
Total memory: 927 TB
3 racks (83 nodes total) enhanced with NVIDIA graphics processing units (GPUs)
614,400 CUDA cores
0.646 Pflop/s total

Estimate the cost of the memory alone: at $5/GB, the estimate is $5 million.

You will have to provide about 1 MW electric power, air conditioning, buildings to house it all, people to run and maintain, ...
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Sun Sep 06, 2020 3:24 am    Post subject: Reply with quote

This power is not always used by single user, the user may get access only to 0.01% of such resources for example. Graphics processors specifically are new and rarely used now by majority of users.

I hate documentations but since you shocked me with such unusual claim, i looked at this code Documentation:

Quote:
For simple cases with good meshes (think isolated wing with a pyHyp) mesh and a modest number of cells (<1M), CPPH can exceed 1 million.

As a concrete example:

450k mesh
4 processors (Desktop machine)
400 sec solution time
CPPH = 1 012 500

For much larger and more difficult case, such as complete configuration: wing, body, nacelle, pylon, h-stab and v-stab, the CPPH may be much lower ~200,000.

Another example:

5 200 000 cell mesh
64 processors
1200 sec solution time
CPPH = 244 000

These values are typical of using the NKSolver in transonic flow from freestream condition with a reasonably efficient Runge-Kutta/DADI start-up procedure before the NKSolver starts.


So this code uses almost exactly what i wrote above as usually without reading any documentations Smile
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Sun Sep 06, 2020 8:07 am    Post subject: Reply with quote

Dan

With regard to item 2, if you can provide details of common MAKE statements that do not work with MK32 then we can look them.
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Sun Sep 06, 2020 7:28 pm    Post subject: Reply with quote

Paul,

May be all statements work OK, the point is that each compiler has its own MAKE differences and would be probably good to select couple most used ones and make sure that FTN95 will accept foreign language statements without changes. Things are that rarely who will help with MAKE usually, in this community for example almost no one uses it. MAKE has only may be 10 words but still it is one more foreign language, it is not a Fortran, not C, not MSDOS, not Linux, it is something no one knows or remembers for sure.

I have 100+ k size MAKEFILE created by some developers over 50 years, where they collected all specific statements from practically all Fortran compilers for Windows, Unix, Mac, Sun etc. There is no entry probably just for FTN95 and i failed to make one ones i was forced to compile their code. I just compiled it usual way via BAT file (which as we all know works with this compiler almost as fast). I can send you this 100k file (and the whole code too) to look if my claim to make MAKE compatible with couple most used Fortran compilers is reasonable and feasible. Be warned, in this file even devil will break his leg Smile
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Sun Sep 06, 2020 8:05 pm    Post subject: Reply with quote

Dan

Given the limited use of MAKE utilities, it does not seem sensible to research the differences that you refer to but do not detail. If you are able to provide detailed information then it may be feasible to correct any deficiencies.
Back to top
View user's profile Send private message AIM Address
wahorger



Joined: 13 Oct 2014
Posts: 1214
Location: Morrison, CO, USA

PostPosted: Mon Sep 07, 2020 3:07 am    Post subject: Reply with quote

While not an expert in MAKE and its variants, I did "roll my own" for my particular project. I might (repeat MIGHT) be able to help "decode" which of the multiple utilities you might be able to use.

Not all variants of MAKE are created equal.

I am using MAKE found with MINGW32. It most closely matched the syntax used in Plato (my original guide to rolling my own).
Back to top
View user's profile Send private message Visit poster's website
JohnCampbell



Joined: 16 Feb 2006
Posts: 2551
Location: Sydney

PostPosted: Mon Sep 07, 2020 7:50 am    Post subject: Re: Reply with quote

DanRRight wrote:
May be also good to add support for reading/writing HDF5 files as the read/write speeds there 10 times faster than unformatted read/write.

I know little of HDF5 file structures, but it sounds like a significant project. It needs someone to investigate a project development approach.

My testing of read/write speeds has been difficult to identify the limits on transfer rates.
1) there are different types of drives; HDD, SATA SSD, M.2 NVMe SSD or PCIe NVMe SSD. Understanding the limiting transfer rates from the SSD type has been confusing.
2) there are different types of buffering, both in the SSD and also via Windows 7/10 memory buffering.
3) transfer rates vary, depending on read or write and sequential or random access. Random access to SSD can be slow.
4) there is a limiting transfer rate, due to compiler/program processing rates.

I struggle to achieve transfer rates approaching 3 GBytes/sec quoted for NVMe drives, as my programs often don't support this data processing rate.

For testing write rates, tests are often muffled by Windows disk buffering, while read tests can also be affected by pre-loading files into memory buffers. The only way to overcome memory buffers (and SSD memory buffers) in testing is to use very large files, but this may not be a "real usage" test.

The I/O speed solution is to first get an NVMe SSD, buy extra memory for disk buffers (say 16 GB) then try to write code that can support transfer rates in excess of 3 GBytes/sec, which is in excess of 1 byte per processor cycle. (use array syntax?)

My related change requests for FTN95 for this performance could include:
1) Adapt TRANSPARENT I/O to support STREAM I/O syntax, including POS=.
2) Provide a binary unformatted file format that is compatible with ifort and gFortran, being a 4-byte header, rather than FTN95's 1/5 byte syntax. (not sure what is used for records > 2 GBytes) Could this be achieved as a compiler option or OPEN ( ACCESS= or FORM= or other ) ?

I do not know what would be required for FTN95 to provide compatible Derived Type I/O, but support for compatible UNFORMATTED files for implicit types would be a start.

ACCESS=DIRECT is already compatible with ifort and gFortran, excluding RECL is measured in file storage units. These do not have record headers.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Mon Sep 07, 2020 8:39 am    Post subject: Reply with quote

John

Someone else has recently noted the absence of the Fortran 2003 STREAM I/O syntax. I will note your request. At the moment I don't know how much work would be required for this.
Back to top
View user's profile Send private message AIM Address
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Mon Sep 07, 2020 10:30 am    Post subject: Reply with quote

I thought that Dan's 1-2-3 list above was useful.

E
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Mon Sep 07, 2020 12:45 pm    Post subject: Reply with quote

One aspect of FTN95 that will need to be fixed in order to enable users to say

make FC = FTN95

is to remove the existing limitations on specifying command arguments to FTN95, and to enable FTN95 to call the linker with existing libraries and object files as input. For example, he following are some options/combinations that are rejected at present:

ftn95 a.f b.obj
ftn95 a.f b.obj c.lib -o my.exe
ftn95 /c a.f
ftn95 /lis a.f90

The absence of support for stream I/O in FTN95, coupled with the peculiar format used for unformatted files, makes it a chore to interoperate with other compilers.

The proprietary 64-bit OBJ file format is an obstacle to using standard Microsoft, Mingw and other tools that process object files, object libraries and debug symbols. The ABI needs a write-up.

Given the amount of work that will probably be needed to make FTN95 work with objects and libraries compiled by other compilers, I suspect that FTN95 will probably have to be content with being a highly useful but niche compiler.


Last edited by mecej4 on Mon Sep 07, 2020 1:52 pm; edited 1 time in total
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7912
Location: Salford, UK

PostPosted: Mon Sep 07, 2020 1:27 pm    Post subject: Reply with quote

mecej4

Quote:
ftn95 a.f b.obj
ftn95 a.f b.obj c.lib -o my.exe
ftn95 /c a.f
ftn95 /lis a.f90


These should be relatively easy to implement.

1) the minus sign is currently an alternative to /.
2) /no_code is the equivalent of /c. Does it have to be /c?
3) What is wrong with /lis?
Back to top
View user's profile Send private message AIM Address
mecej4



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Mon Sep 07, 2020 1:48 pm    Post subject: Re: Reply with quote

PaulLaidler wrote:


...
2) /no_code is the equivalent of /c. Does it have to be /c?


-c as used in Unix/Linux and other compilers on Windows: compile only, do not link. By default, when -c is not specified, those compiler drivers will produce an OBJ file and then call the linker to work on the OBJ files. So, -c is not the equivalent of /no_code.

FTN95, invoked with /c, offers the user a chance to edit the .CFG file! Any editor can be used to edit that file, and I doubt that such editing is done often.

If -c does not have the traditional meaning of "compile, do not link", Dan's 100 kbyte makefile will have to be edited just for FTN95/MK32, and such editing can make the makefile cease to work. When Make fails, it is often very difficult to find what went wrong and how to recover from the problem.

Quote:
3) What is wrong with /lis?


Here is an example:
Quote:
:\LANG>ftn95 /lis btree.f90
[FTN95/Win32 Ver. 8.65.0 Copyright (c) Silverfrost Ltd 1993-2020]
*** No source file specified
*** Usage: ftn95 <file-name> [/option [/option ...]]
*** Or: ftn95 /? for more information on command-line options.


The command ftn95 btree.f90 /lis, however, works.
In general, the positioning of options should not affect their effects.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group