Present: Frank, Roland, Steve, Peter, Matt, Josh, Erik, Zach, Jonah, Elo
There will be no ET call next week due to labour day/Thanksgiving weekend in North America.
IllnoisGRMHD: * report is with Zach, was send via private email * separate repo is fine, Zach will create a repository * volunteer needed for the compatibility thorn * Zach will move compatibility thorns into same repo as IllinoisGRMHD
GetComponents on OSX: * no OSX user has written * Roland will propose a patch
simfactory on BeeGFS: * Erik will look into Bruno's proposed patch
writing timeseries data into hdf5: * Frank would like to use this for things like the Hamiltonian norm * HDF5 supports extensible datasets, an example on how to use this is the HDF5 output of Multipole
SPH in Cactus: * Matt has a more or less working version of SPH on grid background * came out of work at a national lab on generic grid methods * currently linked in a shared objects for mesh handling and nearest neighbour finding * currently writing his thesis, so code is not changing much right now * load balancing through bisection initially then times the RHS and neighbour looked up push particles around * no octree, instead a hierarchical hash * particle to grid data currently uses SPH approximation for Tmunu at gridpoints of Cactus grid * will arrange for time for presentation through mailing list
Yours, Roland
On 31 Aug 2015, at 17:53, Roland Haas rhaas@aei.mpg.de wrote:
writing timeseries data into hdf5:
- Frank would like to use this for things like the Hamiltonian norm
- HDF5 supports extensible datasets, an example on how to use this is
the HDF5 output of Multipole
I have thought about this a fair amount before. Many thorns use their own output routines because Cactus does not provide what they need. The Cactus output methods are designed to output grid variables and grid arrays, but many thorns would like to output tables of data which do not correspond to Cactus variables. For example, AHFinderDirect and Multipole. PunctureTracker handles this by creating Cactus variables for its data. The down-side to this is that all the "trackers" are always output, leading to a very large number of columns in the ascii output, making it impossible for a human to understand without tedious column-counting. Multipole cannot use this mechanism, because it wants to write ascii files with different names for different l,m,r,var combinations. It could use a 5-dimensional grid array for this, but this would be very wasteful, and also impossible for humans to read. HDF5 output of grid arrays is very immature, and rarely does what you want (e.g. it usually creates one dataset per iteration, making reading the file very tedious).
Instead, I think there should be a Cactus mechanism for outputting "tables" of data to "files". These tables would have named "columns", and the "files" could be real ASCII files, or extensible datasets in HDF5 files. The "rows" of the tables would correspond to output iterations. The data would not have to correspond to Cactus variables. Output would happen via aliased function calls. Probably we would have an initial call to "register" the output table, and subsequent calls to add to it. Whether the output happens via ascii or hdf5 should be transparent to the application code, controlled just by an option somewhere (either in the application, maybe a parameter, similar to how the interpolator options are handled).
Such a system would allow a fair amount of duplicated code and logic to be eliminated, and provide nice clean consistent output files across all thorns that need them. This would also simplify parsing of these files by analysis tools, as the formats would be guaranteed to be the same.
On Wed, Sep 02, 2015 at 10:50:53AM +0200, Ian Hinder wrote:
I have thought about this a fair amount before. Many thorns use their own output routines because Cactus does not provide what they need. The Cactus output methods are designed to output grid variables and grid arrays, but many thorns would like to output tables of data which do not correspond to Cactus variables.
What I was thinking about wasn't grid functions or arrays, but simple scalars (or lists thereof). Cactus does provide output for those, just not in HDF5.
For example, AHFinderDirect and Multipole. PunctureTracker handles this by creating Cactus variables for its data. The down-side to this is that all the "trackers" are always output, leading to a very large number of columns in the ascii output, making it impossible for a human to understand without tedious column-counting.
I agree that outputting invalid data is wasteful. The same happens for spherical surfaces.
Multipole cannot use this mechanism, because it wants to write ascii files with different names for different l,m,r,var combinations.
Indeed. But maybe that's not a good choice to begin with. I for my part would rather have all data in one file. It would make such an ASCII file unreadable, but I rarely open them in an editor anyway.
HDF5 output of grid arrays is very immature, and rarely does what you want (e.g. it usually creates one dataset per iteration, making reading the file very tedious).
I am not sure about all grid arrays (simply didn't think hard enough about it), but something like scalar variables and groups thereof should be 'simple' enough to be output as time series, as one scalar series per dataset, grouped inside hdf5.
Instead, I think there should be a Cactus mechanism for outputting "tables" of data to "files". These tables would have named "columns", and the "files" could be real ASCII files, or extensible datasets in HDF5 files. The "rows" of the tables would correspond to output iterations.
Up to here this is scalar output as we have it.
The data would not have to correspond to Cactus variables.
I think it would be better to make them such. The output routines would need to be a bit cleverer when it comes to their output.
Output would happen via aliased function calls. Probably we would have an initial call to "register" the output table, and subsequent calls to add to it.
So far the workflow was different. You don't register variables to be output. You register variables, and the output thorns decide what gets output (using parameters). This seems cleaner to me, better separated. If this mechanism is missing something, we could think about adding it. What I can think of immediately are two things:
- provide a way to specify 'column names' for each variable This could either be done via tags, and/or via a new CCTK function if we think we need to change this at runtime - provide a way to specify validity of a variable - such that invalid data isn't output (by default) Designing this might be a little harder. We should avoid extra calls just for this. One possibility would be an extra "valid" state for each variable. But that doubles the number of variables and wouldn't work for arrays anyway where only part of it might be valid, and part is not. Leaving arrays aside for a moment, and assuming we would leave the default of this 'state' to 'valid', we could provide a CCTK call for thorns to specify that certain variables do not contain valid data at a given time step. This would be collected as list (of variable ids), and can be used by output thorns.
Frank
Hello all,
So far the workflow was different. You don't register variables to be output. You register variables, and the output thorns decide what gets output (using parameters). This seems cleaner to me, better separated. If this mechanism is missing something, we could think about adding it. What I can think of immediately are two things:
- provide a way to specify 'column names' for each variable This could either be done via tags, and/or via a new CCTK function if we think we need to change this at runtime
- provide a way to specify validity of a variable - such that invalid data isn't output (by default) Designing this might be a little harder. We should avoid extra calls just for this. One possibility would be an extra "valid" state for each variable. But that doubles the number of variables and wouldn't work for arrays anyway where only part of it might be valid, and part is not. Leaving arrays aside for a moment, and assuming we would leave the default of this 'state' to 'valid', we could provide a CCTK call for thorns to specify that certain variables do not contain valid data at a given time step. This would be collected as list (of variable ids), and can be used by output thorns.
Would it already be sufficient to have a thorn IOHDF5Timeseries which provides another output method (along with IOASCII, IOHDF5 and IOScalar) that writes variables as time-series ie. extensible HDF5 datasets with the first dimension being time? If given an option like one_file_per_group it would combine all scalars in a group into different columns of the output dataset. It would not be able to write grid functions (or slices of them) since their extent can change during the simulation but it would be able to write SCALARs and ARRAYS as well as 0d data. The thorn would write one HDF5 dataset per Cactus variable. This would mean that the new output method behaves very much like the current ones and is more or less the equivalent CarpetIOASCII's compact output format which works decently well for ASCII timeseries output.
Yours, Roland
On Wed, Sep 02, 2015 at 09:55:39PM -0400, Roland Haas wrote:
Would it already be sufficient to have a thorn IOHDF5Timeseries which provides another output method (along with IOASCII, IOHDF5 and IOScalar) that writes variables as time-series ie. extensible HDF5 datasets with the first dimension being time? If given an option like one_file_per_group it would combine all scalars in a group into different columns of the output dataset. It would not be able to write grid functions (or slices of them) since their extent can change during the simulation but it would be able to write SCALARs and ARRAYS as well as 0d data. The thorn would write one HDF5 dataset per Cactus variable. This would mean that the new output method behaves very much like the current ones and is more or less the equivalent CarpetIOASCII's compact output format which works decently well for ASCII timeseries output.
It would solve the "HDF5" issue, but not the one Ian mentioned: that sometimes data can be invalid. We don't have a good mechanism for thorns to mark data as currently invalid (e.g. AHFinder quantities).
Frank
Present: Frank, Roland, Steve, Erik, Elo, Peter, Ian
svn certificate at LSU: * add specific case for LSU checkouts which are currently broken * Frank to ask Barry, who currently seem the only one that can do this, on the process of converting to git for use in bitbucket
CamelCase repository names: * will close as "wontfix" since we expect the breakage due to changes in the name will be larger than the small benefit from have nicer looking names
Explicit processor independent test suite data comparison: * Roland is worried that Steve's patch assumes meaning for the columns and that there are (or are in private thorns) files that do not conform to the assumed format since eg waveform output can contain only time, real part of psi4 and imaginary part of psi4. Differences in ghost zones may also not be caught * Carpet's compact output format with disabled ghost zone output provides this facility and Steve is going to look at the McLachlan tests that use this * request to add this information to the wiki page on making a test
Yours, Roland
Present: Steve, Roland, Elo, Frank, Peter, Zach, Matt, Barry,
* ET servers are back up now. * accept seedmangneticfield thorn from WVUThorns * Zach added documentation on correctness test to WVUThorns * Zach will make thorndoc tex files so that it appears in Thorndoc.pdf and the online documentation
* no change yet to the ExternalLibraries, will probably do this week * LSUThorns are moved to bitbucket and thornlist is updated * AEIThorns are moved to bitbucket and thornlist is updated * wait for ExternalLibraries cleanup before splitting off tarballs
* single timelevel use in Carpet: works after commenting our error check
Yours, Roland
Thanks for the minutes, Roland! Also, thanks to Frank for reviewing the last remaining un-reviewed thorn in the WVUThorns arrangement.
* Zach will make thorndoc tex files so that it appears in Thorndoc.pdf
and the online documentation
I have just committed thorndoc tex files for all thorns within the WVUThorns arrangement.
Please let me know if there are any remaining concerns regarding WVUThorns incorporation into the next ET release.
On Mon, Oct 12, 2015 at 11:26 AM, Roland Haas < roland.haas@physics.gatech.edu> wrote:
Present: Steve, Roland, Elo, Frank, Peter, Zach, Matt, Barry,
- ET servers are back up now.
- accept seedmangneticfield thorn from WVUThorns
- Zach added documentation on correctness test to WVUThorns
- Zach will make thorndoc tex files so that it appears in Thorndoc.pdf
and the online documentation
- no change yet to the ExternalLibraries, will probably do this week
- LSUThorns are moved to bitbucket and thornlist is updated
- AEIThorns are moved to bitbucket and thornlist is updated
I did not notice this before, but: AEIThorns/TensorTypes is required by the Llama multi-block infrastructure. We should probably move it to CactusNumerical as well.
-erik
wait for ExternalLibraries cleanup before splitting off tarballs
single timelevel use in Carpet: works after commenting our error check
Yours, Roland
-- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net.
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
On 13 Oct 2015, at 15:33, Erik Schnetter schnetter@cct.lsu.edu wrote:
On Mon, Oct 12, 2015 at 11:26 AM, Roland Haas roland.haas@physics.gatech.edu wrote: Present: Steve, Roland, Elo, Frank, Peter, Zach, Matt, Barry,
- ET servers are back up now.
- accept seedmangneticfield thorn from WVUThorns
- Zach added documentation on correctness test to WVUThorns
- Zach will make thorndoc tex files so that it appears in Thorndoc.pdf
and the online documentation
- no change yet to the ExternalLibraries, will probably do this week
- LSUThorns are moved to bitbucket and thornlist is updated
- AEIThorns are moved to bitbucket and thornlist is updated
I did not notice this before, but: AEIThorns/TensorTypes is required by the Llama multi-block infrastructure. We should probably move it to CactusNumerical as well.
Note that this technically means proposing it for the ET, and making sure that the usual requirements are met.
On 13 Oct 2015, at 15:52, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 13 Oct 2015, at 15:33, Erik Schnetter schnetter@cct.lsu.edu wrote:
On Mon, Oct 12, 2015 at 11:26 AM, Roland Haas roland.haas@physics.gatech.edu wrote: Present: Steve, Roland, Elo, Frank, Peter, Zach, Matt, Barry,
- ET servers are back up now.
- accept seedmangneticfield thorn from WVUThorns
- Zach added documentation on correctness test to WVUThorns
- Zach will make thorndoc tex files so that it appears in Thorndoc.pdf
and the online documentation
- no change yet to the ExternalLibraries, will probably do this week
- LSUThorns are moved to bitbucket and thornlist is updated
- AEIThorns are moved to bitbucket and thornlist is updated
I did not notice this before, but: AEIThorns/TensorTypes is required by the Llama multi-block infrastructure. We should probably move it to CactusNumerical as well.
Note that this technically means proposing it for the ET, and making sure that the usual requirements are met.
Actually, no, it doesn't. Moving it to CactusNumerical means adding it to Cactus, not to the ET. We would not add it to the ET thornlist.
On Tue, Oct 13, 2015 at 2:53 PM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 13 Oct 2015, at 15:52, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 13 Oct 2015, at 15:33, Erik Schnetter schnetter@cct.lsu.edu wrote:
On Mon, Oct 12, 2015 at 11:26 AM, Roland Haas < roland.haas@physics.gatech.edu> wrote:
Present: Steve, Roland, Elo, Frank, Peter, Zach, Matt, Barry,
- ET servers are back up now.
- accept seedmangneticfield thorn from WVUThorns
- Zach added documentation on correctness test to WVUThorns
- Zach will make thorndoc tex files so that it appears in Thorndoc.pdf
and the online documentation
- no change yet to the ExternalLibraries, will probably do this week
- LSUThorns are moved to bitbucket and thornlist is updated
- AEIThorns are moved to bitbucket and thornlist is updated
I did not notice this before, but: AEIThorns/TensorTypes is required by the Llama multi-block infrastructure. We should probably move it to CactusNumerical as well.
Note that this technically means proposing it for the ET, and making sure that the usual requirements are met.
Actually, no, it doesn't. Moving it to CactusNumerical means adding it to Cactus, not to the ET. We would not add it to the ET thornlist.
It would, however, require a license change to LGPL. Erik is the only author for TensorTypes so the change is straightforward, assuming he approves?
Right, LGPL instead of GPL. Yes, I approve.
-erik
On Tue, Oct 13, 2015 at 9:59 AM, Barry Wardell barry.wardell@gmail.com wrote:
On Tue, Oct 13, 2015 at 2:53 PM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 13 Oct 2015, at 15:52, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 13 Oct 2015, at 15:33, Erik Schnetter schnetter@cct.lsu.edu wrote:
On Mon, Oct 12, 2015 at 11:26 AM, Roland Haas < roland.haas@physics.gatech.edu> wrote:
Present: Steve, Roland, Elo, Frank, Peter, Zach, Matt, Barry,
- ET servers are back up now.
- accept seedmangneticfield thorn from WVUThorns
- Zach added documentation on correctness test to WVUThorns
- Zach will make thorndoc tex files so that it appears in Thorndoc.pdf
and the online documentation
- no change yet to the ExternalLibraries, will probably do this week
- LSUThorns are moved to bitbucket and thornlist is updated
- AEIThorns are moved to bitbucket and thornlist is updated
I did not notice this before, but: AEIThorns/TensorTypes is required by the Llama multi-block infrastructure. We should probably move it to CactusNumerical as well.
Note that this technically means proposing it for the ET, and making sure that the usual requirements are met.
Actually, no, it doesn't. Moving it to CactusNumerical means adding it to Cactus, not to the ET. We would not add it to the ET thornlist.
It would, however, require a license change to LGPL. Erik is the only author for TensorTypes so the change is straightforward, assuming he approves?
Hello all,
It would, however, require a license change to LGPL. Erik is the only author for TensorTypes so the change is straightforward, assuming he approves?
The thorn is lacking documentation unfortunately. Since this is an infrastructure thorn, it would be very nice if there was documentation describing its exported functions and what they do. Some of it is "obvious" like TT_varindex2tensortype others, like the num_derivs argument to TT_derivative are not so clear (namely: is this just the number of nabla's applied to the tensor or something similar to the derivative argument of AEILocalInterp where 12 would mean to take the derivative \partial_x \partial_y?).
A test suite wold also be very useful so that all tensor types are exercised at least once (think of the bugs we had in RK68 in MoL since there were no test cases for it). Does such a one perhaps already exist in the form of a TestTenstorTypes thorn somewhere?
Otherwise: yes this is a thorn we dearly want to have available in Cactus to make it easier to deal with for example symmetries.
Yours, Roland
Good point. But yes, this should probably go into Cactus; this thorn was intended to collect common code from various symmetry thorns that is currently repeated in multiple places. It's already GPL.
-erik
On Tue, Oct 13, 2015 at 9:53 AM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 13 Oct 2015, at 15:52, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 13 Oct 2015, at 15:33, Erik Schnetter schnetter@cct.lsu.edu wrote:
On Mon, Oct 12, 2015 at 11:26 AM, Roland Haas < roland.haas@physics.gatech.edu> wrote:
Present: Steve, Roland, Elo, Frank, Peter, Zach, Matt, Barry,
- ET servers are back up now.
- accept seedmangneticfield thorn from WVUThorns
- Zach added documentation on correctness test to WVUThorns
- Zach will make thorndoc tex files so that it appears in Thorndoc.pdf
and the online documentation
- no change yet to the ExternalLibraries, will probably do this week
- LSUThorns are moved to bitbucket and thornlist is updated
- AEIThorns are moved to bitbucket and thornlist is updated
I did not notice this before, but: AEIThorns/TensorTypes is required by the Llama multi-block infrastructure. We should probably move it to CactusNumerical as well.
Note that this technically means proposing it for the ET, and making sure that the usual requirements are met.
Actually, no, it doesn't. Moving it to CactusNumerical means adding it to Cactus, not to the ET. We would not add it to the ET thornlist.
-- Ian Hinder http://members.aei.mpg.de/ianhin
On Tue, Oct 13, 2015 at 03:53:46PM +0200, Ian Hinder wrote:
Note that this technically means proposing it for the ET, and making sure that the usual requirements are met.
Actually, no, it doesn't. Moving it to CactusNumerical means adding it to Cactus, not to the ET. We would not add it to the ET thornlist.
It doesn't mean proposing it for the ET, but I imagine we should have similar ideals for Cactus as well, if not the same. Moving a thorn into a Cactus arrangement means that we "officially" maintain it. We cannot allow just any thorn in. Of course, this isn't anything against TensorTypes - just a general statement.
Frank
On Tue, Oct 13, 2015 at 3:49 PM, Frank Loeffler knarf@cct.lsu.edu wrote:
On Tue, Oct 13, 2015 at 03:53:46PM +0200, Ian Hinder wrote:
Note that this technically means proposing it for the ET, and making
sure that the usual requirements are met.
Actually, no, it doesn't. Moving it to CactusNumerical means adding it
to Cactus, not to the ET. We would not add it to the ET thornlist.
It doesn't mean proposing it for the ET, but I imagine we should have similar ideals for Cactus as well, if not the same. Moving a thorn into a Cactus arrangement means that we "officially" maintain it. We cannot allow just any thorn in. Of course, this isn't anything against TensorTypes - just a general statement.
I have added TensorTypes to the CactusNumerical arrangement and switched its license to LGPL.
On Mon, Oct 12, 2015 at 05:26:18PM +0200, Roland Haas wrote:
- no change yet to the ExternalLibraries, will probably do this week
I changed the previous version used for HDF5 and committed it again (it failed before on Stampede). I tested it on Debian, Supermike and Stampede. Please test it as you like. Before I go on using these for the other libraries I would like to know that there are at least no failures on machines where it worked beforehand, and it would also be nice to get reports if previously undetected system installations finally get picked up (multi-arch and such).
Frank
Present: Frank, Eloisa, Roland, Matt, Josh, Yosef, Ian, Zach
Tickets for the release: * still missing is LORENE * IllinoisGRMHD currently has only the evolution thorn in. All reviewed ones should go in. * add qc0 example to gallery, make sure that the gallery examples run * gallery example for CT_Multilevel still being worked on (Eloisa, Ian) will be included * external libraries detection mechanism ** would like to be able to test more tests inside the script ** since it is hard to test all on a single system, would like to have artificial testing infrastructure to make a "fake" library installation ** needs to go through review process before release ** will continue discussion offline * include elliptic solver CT_MultiLevel, current testsuite failures are tracked down due to changes of constraints in McLachlan rewrite. Expect roundoff level changes in ML which may be amplified so this does not block the release. Remove ML from test if the test does not actually evolve anything. * deprecate parameters in GRHydro that are only used by F90 code. Want to eventually remove F90 code.
Compact format for test cases: * Steve finds that sometimes he finds multiple identical lines when running on multiple processors * checked that it is not ghost zones
Yours, Roland
On 10/19/2015 10:45 AM, Roland Haas wrote:
Present: Frank, Eloisa, Roland, Matt, Josh, Yosef, Ian, Zach
Steve was there at the end!
Cheers, Steve
Tickets for the release:
- still missing is LORENE
- IllinoisGRMHD currently has only the evolution thorn in. All reviewed
ones should go in.
- add qc0 example to gallery, make sure that the gallery examples run
- gallery example for CT_Multilevel still being worked on (Eloisa, Ian)
will be included
- external libraries detection mechanism
** would like to be able to test more tests inside the script ** since it is hard to test all on a single system, would like to have artificial testing infrastructure to make a "fake" library installation ** needs to go through review process before release ** will continue discussion offline
- include elliptic solver CT_MultiLevel, current testsuite failures are
tracked down due to changes of constraints in McLachlan rewrite. Expect roundoff level changes in ML which may be amplified so this does not block the release. Remove ML from test if the test does not actually evolve anything.
- deprecate parameters in GRHydro that are only used by F90 code. Want
to eventually remove F90 code.
Compact format for test cases:
- Steve finds that sometimes he finds multiple identical lines when
running on multiple processors
- checked that it is not ghost zones
Yours, Roland
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Present: Frank, Roland, Elo, Josh, Ian, Erik, Steve, Peter
Blocking access to trunk in repos that moved to git * two options: (a) remove all files instead of README file explaining where to get the (b) remove or move trunk branch * test until next week, use whatever breaks least but gives a useful error message
Release: * full freeze on Monday Nov 9th, release later during that week * Erik will re-run the tests on all machines, results are uploaded to https://build.barrywardell.net/view/EinsteinToolkitMulti/job/EinsteinToolkit... and eventually also to the ET website * name: Somerville
Gallery: * Frank to re-run the BNS run * Roland to re-run BNS * Peter to provide QC0 example
Yours, Roland
Present: Frank, Roland, Ian, Matt, Jonah, Peter, Josh, Erik, Zach
Release: * one some machines SphericalHarmonicReconGen * LocalInterp2 shows failures, Roland suspects this to be related to . Disable the test if this is the case. * datura tests are outdated, Ian tested more recently, will sort out access issues for Erik * Frank will go ahead with the release plans, changes from now on need to be committed to both master and the release branch
Next release: * include new version of LORENE * changes to EOS handling in GRHydro * updates to IllinoisGRMHD * updated ExternalLibraries scripts
No meeting next week due to supercomputing.
Yours, Roland
Hi,
A list of testsuites run on different machines can be found here:
https://build.barrywardell.net/view/EinsteinToolkitMulti/job/EinsteinToolkit...
Frank
Present: Frank, Roland, Yosef, Eloisa, Erik
HDF5 auto-detection: * Yosef reports that some installations use a file H5pub.h H5pub_x86.h (or similar) * Yosef will create a ticket
Tracers in GRHydro: * implement Ian Hawke's proposed solution
LORENE: * provide LORENE thorn LORENE format introduced * poll users and once majority uses the newer version, then switch over
Release process: * Roland asks for opinions on the release process ** timeliness ** care taken releasing it ** participation of maintainers * Erik mentions that if there are no large changes and the community does not request them this frequent, then it may not be required to have a release every 6 months * Frank uses regular 6 monthly releases so that there is a fairly modern released and tested version to base new projects off * Roland suggests that a release should have a clear "extra value" compared to trunk from two weeks ago. Suggest to have a major new feature (like IllinoisGRMHD, or MHD) or at least if we claim it to be stable code we should be able to show proof of this by having some largish science simulations that are doable * Eloisa suggests to not insist on this to stringently on always having a major new feature and set a goal that is so ambitious that we let the releases slip. Having fewer releases may not actually mean less work overall since larger intervals accumulate more changes that are then harder to track. * suggestions for groups: ** showcase about DG methods from Erik ** BNS with Llama from Roland ** Yosef help for BBH
There will be a ET meeting next week Monday again (after US Thanksgiving).
Yours, Roland
On 23 Nov 2015, at 18:02, Roland Haas roland.haas@physics.gatech.edu wrote:
Present: Frank, Roland, Yosef, Eloisa, Erik
HDF5 auto-detection:
- Yosef reports that some installations use a file H5pub.h H5pub_x86.h
(or similar)
- Yosef will create a ticket
Tracers in GRHydro:
- implement Ian Hawke's proposed solution
LORENE:
- provide LORENE thorn LORENE format introduced
- poll users and once majority uses the newer version, then switch over
Release process:
- Roland asks for opinions on the release process
** timeliness ** care taken releasing it ** participation of maintainers
- Erik mentions that if there are no large changes and the community
does not request them this frequent, then it may not be required to have a release every 6 months
- Frank uses regular 6 monthly releases so that there is a fairly modern
released and tested version to base new projects off
- Roland suggests that a release should have a clear "extra value"
compared to trunk from two weeks ago. Suggest to have a major new feature (like IllinoisGRMHD, or MHD) or at least if we claim it to be stable code we should be able to show proof of this by having some largish science simulations that are doable
- Eloisa suggests to not insist on this to stringently on always having
a major new feature and set a goal that is so ambitious that we let the releases slip. Having fewer releases may not actually mean less work overall since larger intervals accumulate more changes that are then harder to track.
- suggestions for groups:
** showcase about DG methods from Erik ** BNS with Llama from Roland ** Yosef help for BBH
There will be a ET meeting next week Monday again (after US Thanksgiving).
Hi,
Apologies for missing the call; I have a conflicting telecon. One thing which is not mentioned above is the value of having the release for making sure that it still runs and the tests pass on most machines. I think that this is a sufficient justification for making a release every 6 months, even if there are no new features. Both the code and the machines change with time, and there is no guarantee that the last release still works on updated clusters, and no guarantee that the tests will still pass on all machines after the code changes that were in trunk.
I think the thing that concerned me slightly about this release was the number of failing tests across the machines which were tested. https://build.barrywardell.net/view/EinsteinToolkitMulti/job/EinsteinToolkit... We only had 4 machines which passed all the tests.
For me, the greatest value in a release is the "quality assurance" that comes with it. This was one of the aims of the ET in the first place. I think I was not paying enough attention at the time of the release, but was it discussed on a telecon that we were "ready to release", and this decision signed off on by some of the maintainers? I wasn't actually aware that it was final before receiving the email from Frank to the list.
Present: Frank, Roland, Erik, Steve, Peter, Barry, Zach, Ian, Oleg
certificates: * fixed now, multiple missed reminder emails, Frank will try and make sure that multiple persons at LSU IT support know how to create the certificate * we are not allowed to install our own, self-purchased tickets * Frank will stress the importance of having valid certificates
Summer school (June 2016): * code design: physics, math, computer science, BNS merger * for middle of PhD thesis (2nd year) * we are happy to have this advised, Oleg will send emailcat
LORENE: * no reply to call for users * will open ticket for users to have a look at new version * if there is no reply, make new version the default
Yours, Roland
Present: Frank, Roland, Erik, Steve, Ian, Philipp
Carpet bboxset2 fix: * will be backported * symptom was the carpet would always combine multiple components
Tracers in GRHydro: * Philipp will contact Ian Hawke
Search paths for Fortran modules: * need to specify in -I even if in /usr/include which we normally filter out * Frank will add an new variable FINC_DIRS that will be only used for Fortran include directories
Stampede performance and performance control: * desire to have 5minute lang performance benchmark * Erik suggest to use the memspeed thorn * Erik runs timing benchmarks with actual parfiles (similar to the XiRel benchmarks) * Frank will setup facilities for Erik to upload these results to
clang format: * config file format is version specific, current one works for 3.6 and 3.7 but not for 3.5 * fix clang version to 3.7, update requirement when new clang version is released
HDF5 build issue: * add option to override MPI detection in HDF5, Steve and Frank will look into this
The next ET call January 11th.2016.
Yours, Roland
On 14 Dec 2015, at 17:31, Roland Haas rhaas@aei.mpg.de wrote:
Present: Frank, Roland, Erik, Steve, Ian, Philipp
Carpet bboxset2 fix:
- will be backported
- symptom was the carpet would always combine multiple components
This has already been backported.
On Mon, Dec 14, 2015 at 11:45 AM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 14 Dec 2015, at 17:31, Roland Haas rhaas@aei.mpg.de wrote:
Present: Frank, Roland, Erik, Steve, Ian, Philipp
Carpet bboxset2 fix:
- will be backported
- symptom was the carpet would always combine multiple components
This has already been backported.
Yes, in git it has been backported. The tarballs still need to be updated. ( http://einsteintoolkit.org/tarballs/)
On Mon, Dec 14, 2015 at 5:30 PM, Zach Etienne zachetie@gmail.com wrote:
On Mon, Dec 14, 2015 at 11:45 AM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 14 Dec 2015, at 17:31, Roland Haas rhaas@aei.mpg.de wrote:
Present: Frank, Roland, Erik, Steve, Ian, Philipp
Carpet bboxset2 fix:
- will be backported
- symptom was the carpet would always combine multiple components
This has already been backported.
Yes, in git it has been backported. The tarballs still need to be updated. (http://einsteintoolkit.org/tarballs/)
And maybe there should also be a new release (ET_2015_11_v1) created?
On 14 Dec 2015, at 19:04, Barry Wardell barry.wardell@gmail.com wrote:
On Mon, Dec 14, 2015 at 5:30 PM, Zach Etienne zachetie@gmail.com wrote:
On Mon, Dec 14, 2015 at 11:45 AM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 14 Dec 2015, at 17:31, Roland Haas rhaas@aei.mpg.de wrote:
Present: Frank, Roland, Erik, Steve, Ian, Philipp
Carpet bboxset2 fix:
- will be backported
- symptom was the carpet would always combine multiple components
This has already been backported.
Yes, in git it has been backported. The tarballs still need to be updated. (http://einsteintoolkit.org/tarballs/)
And maybe there should also be a new release (ET_2015_11_v1) created?
We also have the problem on stampede (https://trac.einsteintoolkit.org/ticket/1850); we should probably wait until both are ready before creating a new point release.
On Mon, Dec 14, 2015 at 05:31:29PM +0100, Roland Haas wrote:
clang format:
- config file format is version specific, current one works for 3.6 and
3.7 but not for 3.5
- fix clang version to 3.7, update requirement when new clang version is
released
The version is now mentioned on the 'downloads' page [1], as is a link to Debian Jessie (stable) backported packages.
Frank
Present: Frank, Steve, Roland, Erik, Ian, Philipp, Josua, Yosef, Eloisa,
ExternalLibraries: * Erik talked to cluster admin who face the same problem. spac: package developed at LLNL is a type of package manager for HPC * URL: https://github.com/LLNL/spack * requires python and probably the usual things (make, sed, etc) * seems to offer all we need and more * handles local patches, build-instructions per architecture, dependencies, uses central mirrors which are populated by tarballs so we could provide "local" tarballs on the cluster * could even be used to download Cactus * needs a bit more work to support crays, pull request is alreday being worked on * no direct support to force same compilers for Cactus and ExternalLibraries. Erik suggests to query spac for the compiler. * supports a lua-based module system
Moving timeslot: * Frank will send around a doodle poll for hours that suit people
Performance on Datura: * problem still exists, needs some testing * affects the release, suggest to comment out offending line to make it work for "most" cases
Phone conference system: * we will try Google hangouts in the future starting from the next call * Frank will send out an email to list detailing requirements * Roland to contact SXS personel to learn about limitations of using Google hangout
No ET meeting on Jan 18th. Next ET call on Jan 25th.
Yours, Roland
On 11 Jan 2016, at 17:53, Roland Haas rhaas@aei.mpg.de wrote:
Performance on Datura:
This is a problem on Stampede, not Datura, and the ticket is https://trac.einsteintoolkit.org/ticket/1850.
Present: Frank, Peter, Matt, Josh, Roland, Barry, Eloisa, Ian, Rahul
hwloc issues (http://lists.einsteintoolkit.org/pipermail/users/2016-February/004707.html): * Frank will look into them
Visualization software to use with Carpet data: * VisIt is currently the most mature support * experimental support in yt, but requires more work to make usable * currently output for 3d data is one file per process, changing to one file per timestep is not straightforward. See thread by http://lists.einsteintoolkit.org/pipermail/users/2016-January/004671.html
ExternalLibraries: * inconsistent user visible interface * rather want cosistent interface than new features for now * current implementation in bash in HDF5 is seen as a starting point, but all agree that having a language with more robust error control would be better (perl or python seem viable options) * all that want to contribute should look at the current bash code to decide which concepts to use and also if switching languages is the right thing to do. This should be done by next week's call. * (added after the call), keep in mind https://github.com/LLNL/spack and the discussion in http://lists.einsteintoolkit.org/pipermail/users/2016-January/004679.html as a possible long term or even currently available solution
Yours, Roland
Hi folks,
On Mon, Feb 15, 2016 at 10:04 AM, Roland Haas rhaas@aei.mpg.de wrote:
Present: Frank, Peter, Matt, Josh, Roland, Barry, Eloisa, Ian, Rahul
hwloc issues ( http://lists.einsteintoolkit.org/pipermail/users/2016-February/004707.html ):
- Frank will look into them
Visualization software to use with Carpet data:
- VisIt is currently the most mature support
- experimental support in yt, but requires more work to make usable
If I remember correctly, Erik had done some work on this -- Erik, is that in a place we could take a look at and try to upstream in yt?
- currently output for 3d data is one file per process, changing to one
file per timestep is not straightforward. See thread by http://lists.einsteintoolkit.org/pipermail/users/2016-January/004671.html
ExternalLibraries:
- inconsistent user visible interface
- rather want cosistent interface than new features for now
- current implementation in bash in HDF5 is seen as a starting point,
but all agree that having a language with more robust error control would be better (perl or python seem viable options)
- all that want to contribute should look at the current bash code to
decide which concepts to use and also if switching languages is the right thing to do. This should be done by next week's call.
- (added after the call), keep in mind https://github.com/LLNL/spack and
the discussion in http://lists.einsteintoolkit.org/pipermail/users/2016-January/004679.html as a possible long term or even currently available solution
Yours, Roland
-- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net. _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Thanks for sending it out.
yt support would be great to have. However, visit can be scripted to get desired slices etc ( http://www.visitusers.org/index.php?title=VisIt-tutorial-Python-scripting). This works on ghpcc cluster of UMASS but, not on stampede right now.
Best, rahul
On Mon, Feb 15, 2016 at 11:09 AM Matthew Turk matthewturk@gmail.com wrote:
Hi folks,
On Mon, Feb 15, 2016 at 10:04 AM, Roland Haas rhaas@aei.mpg.de wrote:
Present: Frank, Peter, Matt, Josh, Roland, Barry, Eloisa, Ian, Rahul
hwloc issues ( http://lists.einsteintoolkit.org/pipermail/users/2016-February/004707.html ):
- Frank will look into them
Visualization software to use with Carpet data:
- VisIt is currently the most mature support
- experimental support in yt, but requires more work to make usable
If I remember correctly, Erik had done some work on this -- Erik, is that in a place we could take a look at and try to upstream in yt?
- currently output for 3d data is one file per process, changing to one
file per timestep is not straightforward. See thread by http://lists.einsteintoolkit.org/pipermail/users/2016-January/004671.html
ExternalLibraries:
- inconsistent user visible interface
- rather want cosistent interface than new features for now
- current implementation in bash in HDF5 is seen as a starting point,
but all agree that having a language with more robust error control would be better (perl or python seem viable options)
- all that want to contribute should look at the current bash code to
decide which concepts to use and also if switching languages is the right thing to do. This should be done by next week's call.
- (added after the call), keep in mind https://github.com/LLNL/spack and
the discussion in http://lists.einsteintoolkit.org/pipermail/users/2016-January/004679.html as a possible long term or even currently available solution
Yours, Roland
-- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net. _______________________________________________ Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Hello all,
If I remember correctly, Erik had done some work on this -- Erik, is that in a place we could take a look at and try to upstream in yt?
I'd like to second this. On top, I can state that I'd actually use yt to visualize some gravitational wave data so there would be some real world test case (and I am fine to spend a bit of time fixing/debugging things).
My recollection is that there were multiple independent attempts to add a Carpet reader to yt (by Frank, Erik/Jonah/Matt, Sherwood). Is that still the case? See http://lists.einsteintoolkit.org/pipermail/users/2015-February/004001.html
Yours, Roland
On 15 Feb 2016, at 17:04, Roland Haas rhaas@aei.mpg.de wrote:
Present: Frank, Peter, Matt, Josh, Roland, Barry, Eloisa, Ian, Rahul
hwloc issues (http://lists.einsteintoolkit.org/pipermail/users/2016-February/004707.html):
- Frank will look into them
Visualization software to use with Carpet data:
- VisIt is currently the most mature support
- experimental support in yt, but requires more work to make usable
- currently output for 3d data is one file per process, changing to one
file per timestep is not straightforward. See thread by http://lists.einsteintoolkit.org/pipermail/users/2016-January/004671.html
ExternalLibraries:
- inconsistent user visible interface
- rather want cosistent interface than new features for now
- current implementation in bash in HDF5 is seen as a starting point,
but all agree that having a language with more robust error control would be better (perl or python seem viable options)
- all that want to contribute should look at the current bash code to
decide which concepts to use and also if switching languages is the right thing to do. This should be done by next week's call.
- (added after the call), keep in mind https://github.com/LLNL/spack and
the discussion in http://lists.einsteintoolkit.org/pipermail/users/2016-January/004679.html as a possible long term or even currently available solution
Regarding the last point, I think we should keep in mind that the thorns in ExternalLibraries currently fulfil two functions. The first is to provide a wrapper to an installed version of the library, and the second is to build and install the library itself. The "spack" project, as well as the library features in simfactory 3, address the second function. We would still need a common interface in ExternalLibraries for the first function, which should work whether the library is installed via Cactus or exists on the system independently. For now, I would focus on this feature, rather than the build/install feature.
Note that there is also a wiki page with some ideas: https://docs.einsteintoolkit.org/et-docs/Improving_the_treatment_of_external....
I'm not sure how much of this is already implemented in Frank's work.
One thing that occurs to me is that the current system might be "too clever", trying to automatically handle many use cases. When looking at updating it, we might consider whether the code can be simplified by allowing just "automatic" or "manual" for each feature, where "automatic" works in very standard cases, but does not try too hard to work in every case. I'm thinking of searching for libraries and headers etc. here.
Hello all,
Regarding the last point, I think we should keep in mind that the thorns in ExternalLibraries currently fulfil two functions. The first is to provide a wrapper to an installed version of the library, and the second is to build and install the library itself. The "spack" project, as well as the library features in simfactory 3, address the second function. We would still need a common interface in ExternalLibraries for the first function, which should work whether the library is installed via Cactus or exists on the system independently. For now, I would focus on this feature, rather than the build/install feature.
ok. Build-install is actually usually the easier thing to do, and hence is our fallback.
One thing that occurs to me is that the current system might be "too clever", trying to automatically handle many use cases. When looking at updating it, we might consider whether the code can be simplified by allowing just "automatic" or "manual" for each feature, where "automatic" works in very standard cases, but does not try too hard to work in every case. I'm thinking of searching for libraries and headers etc. here.
My position is usually: that the automated detection must work on common laptops and workstations since we will use first time users if they download to their workstation and it fails to even compile. My current list of "important" systems is current OSX, Ubuntu Linux (long term stable and current), RedHat Linux and I would expect pkg-config to be present on Linux workstations (but maybe not on OSX?). Beyond that there should be a fully manual mode suitable for clusters. Anything in between I personally would consider "optional".
Yours, Roland
On 15 Feb 2016, at 21:06, Roland Haas rhaas@aei.mpg.de wrote:
Hello all,
Regarding the last point, I think we should keep in mind that the thorns in ExternalLibraries currently fulfil two functions. The first is to provide a wrapper to an installed version of the library, and the second is to build and install the library itself. The "spack" project, as well as the library features in simfactory 3, address the second function. We would still need a common interface in ExternalLibraries for the first function, which should work whether the library is installed via Cactus or exists on the system independently. For now, I would focus on this feature, rather than the build/install feature.
ok. Build-install is actually usually the easier thing to do, and hence is our fallback.
One thing that occurs to me is that the current system might be "too clever", trying to automatically handle many use cases. When looking at updating it, we might consider whether the code can be simplified by allowing just "automatic" or "manual" for each feature, where "automatic" works in very standard cases, but does not try too hard to work in every case. I'm thinking of searching for libraries and headers etc. here.
My position is usually: that the automated detection must work on common laptops and workstations since we will use first time users if they download to their workstation and it fails to even compile. My current list of "important" systems is current OSX, Ubuntu Linux (long term stable and current), RedHat Linux and I would expect pkg-config to be present on Linux workstations (but maybe not on OSX?). Beyond that there should be a fully manual mode suitable for clusters. Anything in between I personally would consider "optional".
Given that we would have to test such an automatic mechanism on the systems that we want to support (RedHat, Ubuntu, etc), it would also be possible to just provide an optionlist for each one. I agree that automatic is better, but if the logic becomes too complicated when trying to work around the idiosyncrasies of a particular platform, then it would be much easier to simplify the logic and set the required options manually in the optionlist.
-- Ian Hinder http://members.aei.mpg.de/ianhin
Hello Ian, all,
Given that we would have to test such an automatic mechanism on the systems that we want to support (RedHat, Ubuntu, etc), it would also be possible to just provide an optionlist for each one. I agree that automatic is better, but if the logic becomes too complicated when trying to work around the idiosyncrasies of a particular platform, then it would be much easier to simplify the logic and set the required options manually in the optionlist.
Yes, there are certainly points where the automatics just fail (a current example is hwloc+numa using static linking on Ubuntu systems). We currently provide option for all of the listed systems and they are somewhat regularly tested (once before each ET release):
https://docs.einsteintoolkit.org/et-docs/Simplified_Tutorial_for_New_Users#C...
The idea behind using pkg-config is that this should continue to work even when there are small changes in the location of libraries etc. It is the difference between using autoconf's configure scripts and hard-coding a set of known paths for supported environments. Basically I think about it like the first answer given here https://www.gnu.org/software/autoconf/manual/autoconf-2.64/html_node/Why-Not...
The option lists are also part of simfactory and usually we would like to avoid very explicit usage of simfactory in core-Cactus functionality.
Yours, Roland
On 15 Feb 2016, at 17:04, Roland Haas rhaas@aei.mpg.de wrote:
ExternalLibraries:
- inconsistent user visible interface
- rather want cosistent interface than new features for now
- current implementation in bash in HDF5 is seen as a starting point,
but all agree that having a language with more robust error control would be better (perl or python seem viable options)
- all that want to contribute should look at the current bash code to
decide which concepts to use and also if switching languages is the right thing to do. This should be done by next week's call.
Hi,
I will not be able to make the call today as I will be travelling at the time; sorry for not realising this last week when proposing this discussion.
I won't be participating either; I have a conflicting physician's appointment.
-erik
On Mon, Feb 22, 2016 at 6:03 AM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 15 Feb 2016, at 17:04, Roland Haas rhaas@aei.mpg.de wrote:
ExternalLibraries:
- inconsistent user visible interface
- rather want cosistent interface than new features for now
- current implementation in bash in HDF5 is seen as a starting point,
but all agree that having a language with more robust error control would be better (perl or python seem viable options)
- all that want to contribute should look at the current bash code to
decide which concepts to use and also if switching languages is the right thing to do. This should be done by next week's call.
Hi,
I will not be able to make the call today as I will be travelling at the time; sorry for not realising this last week when proposing this discussion.
-- Ian Hinder http://members.aei.mpg.de/ianhin
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Present: Jonah, Roland, Frank, Matt, Steve, Josh, Eloisa
ExternalLibraries: * postponed due to missing participants * commit patch to allow manualconfiguration of hdf5 paths
Yours, Roland
Present: Steve, Frank, Eloisa, Roland Ian, Josh, Erik, Matt,
ExternalLiraries/HDF5: * Steve and Erik to communicate offline * Erik will clean up the script
ExternalLibraries helper tools: * step in the right direction, namely factoring out common facility * would prefer if less global state was used * keep in bash, return values the way eg ssh-agent does, namely as eval assignments ie: find_libs outputs "LIBS=XXX" * if we decide for a more powerful language we favor perl over python * Erik will implement a sample perl code for FFTW3
Yours, Roland
Present: Eloisa, Josh, Frank, Roland, Steve, Matt, Erik
OPENSSL vraiable names: * start variable names with thorn name so OPENSSL_DIR rather than SSL_DIR
Generate parameter files from fragments using a type of web-interface: * there seems to be no direct interest
Autodetection scripts: * Erik rewrote the detect.sh script in perl (example FFTW3) * Frank and Roland have interest in working on these
Yours, Roland
Present: Erik. Roland, Josh, Matt, Ian, Steve, Frank, Eloisa, Peter
Perl ExternalLibraries: * Erik is rewriting the HDF5 one using perl, though is not yet finished * generally need to make sure that if user specifies HDF5_INC_DIRS HDF5_LIB_DIRS HDF5_LIBS then we trust the user and don't second guess her
General ExternalLibraries: * slowly move away from building them inside of Cactus * rather have build system outside of Cactus and use the build libraries that way
Yours, Roland
Present: Frank, Ian, Roland, Steve, Philipp, Josh, Yosef, Zach,
Performance on stampede:
* the sub-optimal interaction between KMP_AFFINITY, tacc_affinity and SystemTopology persists and limits run speed * for Ian removing KMP_AFFINITY fixed it, David's issue seemed more complex and Ian will read up on the ticket
Make Refluxing thorn agnostic to GRHydro: * Frank and Roland will look at David's proposed branch
Yours, Roland
Hi all,
I tried connecting to the weekly telecon this morning, but had wifi problems. Back when I filled out the Doodle poll at the start of the semester, there was a timezone issue, and I filled out the wrong times by mistake. Bottom line is, I have teaching duties during the telecon. This week is Spring Break, so I was able to (attempt to) call in.
Status update: Work continues on ILGRMHD, though mostly on associated diagnostic thorns. I intend to propose inclusion of at least some of these (quite useful) thorns over the summer. I also plan to take a close look at David's very nice refluxing patch and test it out with ILGRMHD.
-Zach
* * * Zachariah Etienne Assistant Professor of Mathematics West Virginia University
On Mon, Mar 21, 2016 at 10:39 AM, Roland Haas rhaas@aei.mpg.de wrote:
Present: Frank, Ian, Roland, Steve, Philipp, Josh, Yosef, Zach,
Performance on stampede:
- the sub-optimal interaction between KMP_AFFINITY, tacc_affinity and
SystemTopology persists and limits run speed
- for Ian removing KMP_AFFINITY fixed it, David's issue seemed more
complex and Ian will read up on the ticket
Make Refluxing thorn agnostic to GRHydro:
- Frank and Roland will look at David's proposed branch
Yours, Roland
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Present: Eloisa, Erik, Frank, Jonah, Steve, Roland, Matt, Ian
* Steve wrote a thorn that uses Carpet's ScheduleWrapper calls to check the READ/WRITE statements of the schedule * will always check WRITEs using checksums * if include helper include file it overwrites CCTK_VatDataPtr to return NULL for all variables that are not declared as READ/WRITE * desire to have it call SYNC if required, this aborts if one is not in LEVEL mode. This is by design since SYNC is a per-level routine. * work is required to get this to work for MoL and Boundary * currently work in progress
Yours, Roland
Present: Ian, Roland, Frank, Jonah, Matt, Eloisa, Erik, Steve, Pau Figueras
Hello all,
Content for the upcoming release: * add Refluxing changes by David Radice (Roland) * ExternalLibraries detect.sh changes are still ongoing, we consider them as "in progress" and will change again in the future * want fix for stampede for speed regression ** Erik suggests to benchmark multi-threading performance and abort on clusters only ** will set up regular automated performance benchmarks in Jenkins ** Ian to apply change so that it aborts when number of threads from omp_getnumthreads() does not agree with what simfactory requested * PeriodicCarpet gained support for interpolating variables
New toolkits in ET: * want to encourage users of other toolkits to join for example GRChombo ** attempt to invite for ET seminar after release of GRChombo ** about smaller codes that solve interesting physical problems, eg characteristic spectral codes to simulate AdS black hole collisions ** please forward suggestions to Frank Loeffler (knarf@cct.lsu.edu)
Yours, Roland
users@lists.einsteintoolkit.org
-
Barry Wardell -
Erik Schnetter -
Frank Loeffler -
Ian Hinder -
Matthew Turk -
rahul kashyap -
Roland Haas -
Roland Haas -
Steven R. Brandt -
Zach Etienne