Separate system specific and non system specific things in system.make

[tkoskela]

There are a number of non system specific things in system.make that should be taken out and put somewhere else. List includes

• MULT_KERN
• OpenMP (the flag is system specific, the logic whether we use openmp or not isn't)

[davidbowler]

The original intent of system.make (despite its name) was to hold compilation dependent information, whether to do with the system or other options like OpenMP. I think that it's better to keep one file where things like this are set to make life easier for the users - we could change the name, if that's causing significant confusion.

[ilectra]

I'm also in favour of separating the system-specific from non-system specific information. If one wants to run CONQUEST on multiple systems, having it all in one file gets confusing. I'm pretty sure our users can handle 2 files with compilation info 😃 . Maybe we can push the non-system-specific stuff to the main makefile?

[davidbowler]

I would prefer to avoid having users edit the main Makefile; if we want to separate things, then it would make sense to have the following flags in a separate file:

• MULT_KERN
• OMPFLAGS
• OMP_DUMMY
• DIAG_DUMMY

I think that putting all the OpenMP variables together is an important idea. When I first created the ScaLAPACK interface, I introduced DIAG_DUMMY as ScaLAPACK wasn't always available. Since it's now fairly standard, we could just lose DIAG_DUMMY.

[tkoskela]

I agree with avoiding editing the main Makefile. I've made a number of errors working on one machine and then moving to another one for profiling and neglecting the fact that the system.make file compiles a different matrix multiply kernel. I think including two files would be the safest approach, one for the system specifics and another one for other compile-time settings. Perhaps somewhere down the line the system specific stuff could be automated 😉

[tsuyoshi38]

For me, both MULT_KERN and OMPFLAGS sound like system dependent (or job dependent) variables since I would like to change them depending on the efficiency of calculations, which usually depends on systems.
I personally prefer the present style, treating only one file to edit. (because I am lazy...)

[tkoskela]

I would like to make a distinction between purely system-specific configuration that you need to successfully build (e.g. paths to the compiler and libraries, compiler flags), and choices made by the user (e.g. choice of multiply kernel, library version, parallelisation scheme). Ideally, once the system specific configuration is set up you would barely ever have to change it, unless the sysadmins modify the system software stack. So you could focus on the user settings, and those would be portable across different systems.

[tsuyoshi38]

I don't clearly understand the point.
In our case using our supercomputers, we usually need to change the libraries and compiler flags depending on the choice of multiply kernels or parallelisation scheme (OMP parallel or not).
In such cases, do we need to edit two files at the same time?

For now, just tidying up the present system.make file is not enough?