Present: Peter, Steve, Roland, Erik, Josh, Matt, Philipp
* Erik, Ian and Barry are working on simfactory 3 which modularizes simfactory and includes facilities to build ExternalLibraries outside of Cactus ** downloads source code of external libraries only when required ** contact Ian Hinder for access to source code ** Steve asked if the modules in simfactory would be useful as a basis to replace the main Cactus make file with a script ** Erik said that so far simfactory 3 treats Cactus as a black box
* Caltech would like to extend our EOS interface to handle more complex EOS that take an extra independent variable (describing the nuclear composition). ** it is suggested to leave the current EOS calls in place and to add a new set eg including Abar in the new function names ** possibly forward the "old" calls to the new ones, passing NULL for the extra argument ** Fortran callability may be sacrificed in the initial implementation
* currently bluewaters shows a significant regression in run speed that even occurs when using an old executable. The seems possibly related to an update of the MPI stack. Philipp is working with Bluewaters support to fix this. Bluewaters is aware of the problem and Cactus is not the only code affected.
Yours, Roland
On 02/10/2014 11:07 AM, Roland Haas wrote:
Present: Peter, Steve, Roland, Erik, Josh, Matt, Philipp
- Erik, Ian and Barry are working on simfactory 3 which modularizes
simfactory and includes facilities to build ExternalLibraries outside of Cactus ** downloads source code of external libraries only when required ** contact Ian Hinder for access to source code ** Steve asked if the modules in simfactory would be useful as a basis to replace the main Cactus make file with a script ** Erik said that so far simfactory 3 treats Cactus as a black box
It might be useful if SF3 automatically detected when the relevant optionlist had changed.
- Caltech would like to extend our EOS interface to handle more complex
EOS that take an extra independent variable (describing the nuclear composition). ** it is suggested to leave the current EOS calls in place and to add a new set eg including Abar in the new function names ** possibly forward the "old" calls to the new ones, passing NULL for the extra argument ** Fortran callability may be sacrificed in the initial implementation
- currently bluewaters shows a significant regression in run speed that
even occurs when using an old executable. The seems possibly related to an update of the MPI stack. Philipp is working with Bluewaters support to fix this. Bluewaters is aware of the problem and Cactus is not the only code affected.
Yours, Roland
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
On 11 Feb 2014, at 15:30, Steven R. Brandt sbrandt@cct.lsu.edu wrote:
On 02/10/2014 11:07 AM, Roland Haas wrote:
Present: Peter, Steve, Roland, Erik, Josh, Matt, Philipp
- Erik, Ian and Barry are working on simfactory 3 which modularizes
simfactory and includes facilities to build ExternalLibraries outside of Cactus ** downloads source code of external libraries only when required ** contact Ian Hinder for access to source code ** Steve asked if the modules in simfactory would be useful as a basis to replace the main Cactus make file with a script ** Erik said that so far simfactory 3 treats Cactus as a black box
SimFactory 3 supports multiple user-defined "applications", of which Cactus is just one. As such, Cactus-specific knowledge is compartmentalised. In my opinion, simfactory should know as little about cactus as possible; we will add convenience features on top of the cactus build system because the cactus build system lacks them, but this is a pragmatic solution – ideally the cactus build system would be improved and this extra layer could be removed from simfactory, but that is more complicated as the cactus make system is quite "involved".
It might be useful if SF3 automatically detected when the relevant optionlist had changed.
Yes, we have decided to do that, and also for the thornlist. It was a design decision of versions 1 and 2 that the options should be explicitly imported to the configuration, rather than pointing the configuration to the external file, but I think this leads to too much confusion.
users@lists.einsteintoolkit.org
-
Ian Hinder -
Roland Haas -
Steven R. Brandt