Collaboration with Kuan-Hsun

Team

@Anthony Thornton

@Thomas Weinhart

@Igor Ostanin

@Timo Plath

@Kuan-Hsun Chen

Topics Discussed

Topic	Status

Topic	Status
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