[Users] Einstein Toolkit Meeting Reminder
knarf at cct.lsu.edu
Mon Oct 5 11:10:09 CDT 2015
On Fri, Oct 02, 2015 at 01:06:54PM -0500, Frank Loeffler wrote:
> Please consider joining the weekly Einstein Toolkit phone call at
> 10 am US central time on Mondays. As usual, you can find instructions
Present were: Eloisa, Erik, Frank, Josh, Matt, Peter, Roland, Steve, and
Topics we discussed:
External Libraries: scripts need to be refreshed - to be done by Frank,
timeframe about 2 weeks.
LSUThorns about to be moved to bitbucket: licenses seem to be only
holdup, but status from Barry unknown.
ADMMass -> EinsteinAnalysis
Trigger -> CactusUtils, change to LGPL, ok'ed by all authors
(knarf, rhaas, schnetter)
SystemStatistics -> CactusUtils, change to LGPL, ok'ed by
schnetter, need ok: barry, ianhin
Ian: please ask
AEILocalInterp: Numerical (GPL, and stays GPL)
PunctureTracker: EinsteinAnalysis, change to LGPL, ok'ed by
diener, schnetter, rhaas, need ok: ianhin, koppitz, reisswig
Peter: please ask
IllinoisGRMHD will get testsuites added soon. This will require a new
thorn (for MHD ID). Frank will review (others welcome too of course).
Once testsuites are in (and work), code can be added to ET thornlist.
LORENE: New version is incompatible with old Lorene ID files. There
seems to be interest to keep the old version around, but there is also
interest to have the new in the toolkit. The only (feasible) way to do
this for us without a lot of work would be to have two thorns, one for
each version. However, the problem with that is that only one of them
could be _compiled_ in because of symbol clashes otherwise, and that
would mean we would need to pick a default, and the other version
wouldn't easily be tested (or we add a configuration for that for all ET
tests: jenkins, release testing). Any ideas how to (nicely) solve this?
Erik presented ideas about general (meta)-data that should go into
output files. More about that will be sent to the ET mailing list.
Steve asked about the possibility to disable sub-cycling, only use 1
timelevel, and use adaptive timestepping. The answer to that was that
this is not well (at all) tested, but should work with a few parameter
settings and some slight code changes in special places.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: Digital signature
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20151005/59817b1f/attachment.bin
More information about the Users