Page Comparison

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 much output 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 lvm.

Kuan clearly preferred lvm

Anthony Thornton pointed it is fast with gcc

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

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.

Kuan is happy to be involved.

Fixed point mathematics

None of the MercuryDPM team was familiar with this but we are interested.