Collaboration with Kuan-Hsun

Double versus single procession

Mercury uses Mdouble to definite the precision

Last time @Anthony Thornton moving to single did not give a speed up

However, Gromac does manage to get a factor of four speed up in single procession mode.

Cache misses

We think Mercury is very bad wrt to this. As the particles are scattered all over memory.

We did consider using Morton curves in past to order the particles and maybe reduce cache misses

Output - in progress

We use too many outputs with the buffer flushed e.g. using std::endl

Output can be complied with the use of logger; however, this does need cleaning up and fully implementing.

Parallisation

The paralllel code is availble (Kuan thought not).

We have both MPI and openMP parallasaition.

We will share via this the respectitive reports.

Use in mode hybrid mode and load balancing (runtime adaption) not yet done.

@Sahar Pourandi is consider load balancing as part of here PhD.

Compiler

We use a mix GCC and llvm.

Kuan pointed out that llvm might provide more freedom to optimize from the compilation, by introducing, e.g., customized compiler pass.

@Anthony Thornton pointed it is fast with GCC, as it is a highly optimized de facto compiler over decades.

Kuan’s disclaimer: If there is no human resource to work on this aspect, GCC should still be the best option.

Mercury goal

We explain we aim to be:

• Portable (i.e. should work on all platforms and complier

• Flexible as easy to add new feature and develop new codes

• Also we have many very good low complexity algorithms in MercuryDPM

However we have not really consider code optismation and we should, but we can break the above three items.

Machine learning for calibration - in progress

We explained how ML is used for calibration and how we think this still needs some basic work

We has a BSc chemistry student starting work on this, where Kuan is an external consultant.

Fixed point mathematics

None of the MercuryDPM team was familiar with this but we are interested.
Kuan didn’t check over all the data types in MercuryDPM, but wanted to point out that the large bit data type should only be used when it is necessary. A nice article captures the relationship between data type and the runtime: http://nicolas.limare.net/pro/notes/2014/12/12_arit_speed/

@Anthony Thornton @Thomas Weinhart you might be interested in this article:
https://dl.acm.org/doi/10.1145/3221269.3223036