Team
...
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:
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, where Kuan is an external consultant. |
Fixed point mathematics | None of the MercuryDPM team was familiar with this but we are interested. Anthony Thornton Thomas Weinhart you might be interested in this article: |