Build libROM on Quartz

[siuwuncheung]

To build mgmol with libROM on Quartz:

1. Copy scripts/build_quartz_libROM.sh to parent.
2. csh build_quartz_libROM.sh

[dalg24-jenkins]

Can one of the admins verify this patch?

[Rombur]

OK to test

[oseikuffuor1]

Thanks Tony. This looks good.

[jeanlucf22]

It is nice to share build scripts with everyone, and that is what we have been doing through the repo and scripts directory. But I would not change the CMakeLists.txt now: we don't have a use case. MGmol is not going to call libROM. We are going to build a driver that will use both libROM and MGmol as libraries.

[siuwuncheung]

It is nice to share build scripts with everyone, and that is what we have been doing through the repo and scripts directory. But I would not change the CMakeLists.txt now: we don't have a use case. MGmol is not going to call libROM. We are going to build a driver that will use both libROM and MGmol as libraries.

I attempted to build libROM within MGmol as I thought we are going to build linear subspace projection based ROMs. In this case, the ROM part is intrusive and we need to call libROM within MGmol. This is similarly done in Laghos.

[dreamer2368]

It is nice to share build scripts with everyone, and that is what we have been doing through the repo and scripts directory. But I would not change the CMakeLists.txt now: we don't have a use case. MGmol is not going to call libROM. We are going to build a driver that will use both libROM and MGmol as libraries.

Where do you have in mind to build that driver? If it resides in this repo, are you thinking of having a separate cmakelists.txt for the driver and linking librom only to that driver?

[oseikuffuor1]

@siuwuncheung @dreamer2368, I think @jeanlucf22 's idea is to build MGmol as a library so that we can have drivers that will link to both libROM and MGmol, calling the necessary functions to generate training data as needed. We would then expose more functionality to do the prediction part. I understand the benefit of having direct access to implement calls that might be intrusive, and we may very well do that at some point. But I think this approach is worth exploring since it will also demonstate how other DFT codes may benefit from the techniques we end up developing in libROM (in a less intrusive way). @dreamer2368, what you mention is along the lines of the approach we are thinking. Jean-Luc is working on an initial driver that we can use as a template for other drivers.

[dreamer2368]

@oseikuffuor1
I like the idea. I also think we could simply include/link libROM that is pre-built, not compiling it together with our application.