Hi
Please consider joining the weekly Einstein Toolkit phone call at 10 am US central time on Mondays. As usual, you can find instructions how to join on the following web site:
http://einsteintoolkit.org/community/support/
I short: the number is (+1) 225-578-4942 or (+1) 866-573-0359 and the conference id is 118682#.
My agenda contains:
- Fall workshop - PLEASE let us know if you come [1]! - Hotel booking - Release planning - release date: Mon Oct 24 2011 - freeze date: Mon Sep 26 - the day of the call! - branch name: ET_2011_10 - List of release-concerning bugs [2] - ET paper: proposed "freeze" by Oct 3rd (Mon after this call)
As always: feel free to add to this list.
Frank Loeffler
[1] https://docs.einsteintoolkit.org/et-docs/ET_Workshop_Fall_2011#Fall_Einstein... [2] https://trac.einsteintoolkit.org/query?status=!closed&milestone=ET_2011_...
Present were: Frank, Roland, Peter, Erik, Tanja, Ian, Eloisa, Yosef, Josh, Christian, Peter
Fall workshop: * PLEASE let us know if you come [1]! It helps the planning process * Hotel booking information has been send out via email. Rooms are held until Oct. 10th
ET release: * add python simfactory to thorn list * test Carpet/Hg again * code freeze at end of today (Monday), no more enhancements after that, only bugfixes, please * $HOME/$WORK/etc in simfactory machine files will be used as $HOME etc. since the @ENV(HOME)@ syntax is not yet implemented and the $HOME syntax works for at least some cases where the current one fails * automated testing facilities: Ian will update his script to simfactory/Python and will make it available * apply for common ET allocation (PI: Frank) for testsuites, centralize running of testsuites in a single person in the long run * run testsuites for release:
Datura - Ian Amarok - Peter Hopper - Frank Lonestar - Frank Minkowski - Roland Numrel (gcc&intel) - Peter Bethe - Roland Ranger - Tanja Redshift - Erik Kraken (intel) - Ian Trestles - TDD Pandora - Peter Queenbee - Peter Qezpur - Peter Philip - Frank Orca - Erik (maybe) Zwicky - Roland Cygnus - Tanja NewHorizon - Yosef
Carpet/Hg: * vectorization still fails on some machines using some compiler and some parameter options * Ian, Barry and Erik will discuss off-line * everybody is asked to try if they can reproduce this * blocker for release otherwise !
Yours, Roland
Hello all,
- run testsuites for release:
It might be a good idea to configure the testsuite configurations with DEBUG=yes to catch as many errors as possible (in particular for the daily testsuite runs). Otherwise eg. variables without storage can remain unnoticed under Fortran (while they casue an immediate segfault under C).
Yours, Roland
When running test case, I would use a configuration as similar as possible to production runs, so that errors in production runs are actually caught. There are some differences between debug and optimized configurations, and these are mostly to help people track down problems, not to ensure that optimized configurations are correct. I would thus suggest that running test cases with an optimized configuration is a must, and with a debug configuration is a nice addition.
For example, sometimes code is #ifdef'd out in optimized runs, leading to undefined variables that are well defined when debugging. Another example is vectorization that is (by default) disabled without optimization, because without optimization, compilers often do a really lousy job, and vectorized code thus runs a few times slower than unvectorized code.
Regarding segfaults in Fortran: why don't unallocated variables lead to an error in Fortran? Do you refer to Fortran allocation or Cactus allocations here?
-erik
On Mon, Sep 26, 2011 at 1:20 PM, Roland Haas roland.haas@physics.gatech.edu wrote:
Hello all,
- run testsuites for release:
It might be a good idea to configure the testsuite configurations with DEBUG=yes to catch as many errors as possible (in particular for the daily testsuite runs). Otherwise eg. variables without storage can remain unnoticed under Fortran (while they casue an immediate segfault under C).
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
Hello Erik,
Regarding segfaults in Fortran: why don't unallocated variables lead to an error in Fortran? Do you refer to Fortran allocation or Cactus allocations here?
Cactus allocations. Variables for which no STORAGE statement is active (either global or in the schedule item).
The reason is that (see configs/*/bindings/include/cctk_Arguments.h) you cannot legally pass a NULL pointer as a FORTRAN array subroutine argument, there apparently *has* to be some storage (I guess FORTRAN does no allow zero-sized arrays). So for non-debug runs Cactus passes in the address of a dummy array. This is sufficient to prevent segfaults (even for rather larger grids). Caught me recently when adding the Multipatch hacks to support non-multipatch runs. I was counting on segfaults if I had forgotten any pointers (and for rather large grids, so it is not just a small grid issue that goes away in production runs). I ended up unitialized memory which was mostly 0 so it did not show up in the test (since the variable without storage was kxx in Minkowski spacetime). :-(
Yours, Roland
--8<-- configs/*/bindings/include/cctk_Arguments.h --8<-- /* * References to non-existing or non-allocated variables should be passed * as NULL pointers in order to catch any invalid access immediately * However, this runtime debugging feature may cause problems * with some fortran compilers which require all fortran routine arguments * to refer to a valid memory location (eg. to enable the code optimizer * to generate conditional load/store instructions if applicable). * For this reason, we pass NULL pointers only for debugging configurations, * and a pointer to a user-accessable memory location (a local dummy variable) * otherwise. */ --8<--
I believe this statement is wrong, but lost the corresponding argument a few years ago.
1. The Fortran standard doesn't say anything about C interoperability (well, the new standard does, but we are not talking about these features). Thus it also doesn't speak about "not passing NULL pointers". In fact, the standard doesn't say anything about how variables are passed, or that they are passed by reference (as pointers).
2. Fortran does allow zero-length arrays.
3. From a system level perspective: If you allocate a zero-sized memory region (via libc), then you may receive a NULL pointer. This depends on the implementation. Thus, if a Fortran implementation allocates a zero-sized array, it may also generate a NULL pointer.
4. From a machine language perspective: If you have an array with zero elements, then there are not too many actions you can legally do with it. You can compare the address of the array (i.e. the pointer) to other pointers, and it is conceivable that there may be a Fortran compiler that does check for NULL and then segfaults, but I don't really see the point of doing so. It would be extra work for no benefit. However, you obviously can't use the pointer to access memory, because the array has no elements, so any expression array(idx) would be illegal.
5. The historic cases where passing a NULL pointer to a Fortran routine in Cactus led to segfaults were cases of wrong compiler optimizations. I looked at some of the disassembled code, and it was clear that there were instructions generated to read array elements in cases where the source code didn't do so. For example:
pseudo Fortran: if (shift-has-storage) then bx=betax(i,j,k); else bx=0; endif pseudo assembler: load betax(i,j,k) into bx if not shift-has-storage: set bx to 0
Of course, the real code was more complex, and the compiler's optimzation made a lot of sense (performance wise, apart from being illegal). I reported this problem to Intel, and it was corrected in a later release.
So, let's change this piece of Cactus.
-erik
On Mon, Sep 26, 2011 at 3:56 PM, Roland Haas roland.haas@physics.gatech.edu wrote:
Hello Erik,
Regarding segfaults in Fortran: why don't unallocated variables lead to an error in Fortran? Do you refer to Fortran allocation or Cactus allocations here?
Cactus allocations. Variables for which no STORAGE statement is active (either global or in the schedule item).
The reason is that (see configs/*/bindings/include/cctk_Arguments.h) you cannot legally pass a NULL pointer as a FORTRAN array subroutine argument, there apparently *has* to be some storage (I guess FORTRAN does no allow zero-sized arrays). So for non-debug runs Cactus passes in the address of a dummy array. This is sufficient to prevent segfaults (even for rather larger grids). Caught me recently when adding the Multipatch hacks to support non-multipatch runs. I was counting on segfaults if I had forgotten any pointers (and for rather large grids, so it is not just a small grid issue that goes away in production runs). I ended up unitialized memory which was mostly 0 so it did not show up in the test (since the variable without storage was kxx in Minkowski spacetime). :-(
Yours, Roland
--8<-- configs/*/bindings/include/cctk_Arguments.h --8<-- /* * References to non-existing or non-allocated variables should be passed * as NULL pointers in order to catch any invalid access immediately * However, this runtime debugging feature may cause problems * with some fortran compilers which require all fortran routine arguments * to refer to a valid memory location (eg. to enable the code optimizer * to generate conditional load/store instructions if applicable). * For this reason, we pass NULL pointers only for debugging configurations, * and a pointer to a user-accessable memory location (a local dummy variable) * otherwise. */ --8<--
-- 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
In particular, what Cactus is currently doing is passing an array of size one to the Fortran routine. If the the compiler generates code that accesses this array as if it had the same size as a grid function, this should trigger a segfault. However, given the way the dummy variable is declared, there is actually accessible memory nearby so that there is no sefault. And since this is only a read access there is no bad consequence.
-erik
On Mon, Sep 26, 2011 at 4:15 PM, Erik Schnetter schnetter@cct.lsu.edu wrote:
I believe this statement is wrong, but lost the corresponding argument a few years ago.
- The Fortran standard doesn't say anything about C interoperability
(well, the new standard does, but we are not talking about these features). Thus it also doesn't speak about "not passing NULL pointers". In fact, the standard doesn't say anything about how variables are passed, or that they are passed by reference (as pointers).
Fortran does allow zero-length arrays.
From a system level perspective: If you allocate a zero-sized
memory region (via libc), then you may receive a NULL pointer. This depends on the implementation. Thus, if a Fortran implementation allocates a zero-sized array, it may also generate a NULL pointer.
- From a machine language perspective: If you have an array with zero
elements, then there are not too many actions you can legally do with it. You can compare the address of the array (i.e. the pointer) to other pointers, and it is conceivable that there may be a Fortran compiler that does check for NULL and then segfaults, but I don't really see the point of doing so. It would be extra work for no benefit. However, you obviously can't use the pointer to access memory, because the array has no elements, so any expression array(idx) would be illegal.
- The historic cases where passing a NULL pointer to a Fortran
routine in Cactus led to segfaults were cases of wrong compiler optimizations. I looked at some of the disassembled code, and it was clear that there were instructions generated to read array elements in cases where the source code didn't do so. For example:
pseudo Fortran: if (shift-has-storage) then bx=betax(i,j,k); else bx=0; endif pseudo assembler: load betax(i,j,k) into bx if not shift-has-storage: set bx to 0
Of course, the real code was more complex, and the compiler's optimzation made a lot of sense (performance wise, apart from being illegal). I reported this problem to Intel, and it was corrected in a later release.
So, let's change this piece of Cactus.
-erik
On Mon, Sep 26, 2011 at 3:56 PM, Roland Haas roland.haas@physics.gatech.edu wrote:
Hello Erik,
Regarding segfaults in Fortran: why don't unallocated variables lead to an error in Fortran? Do you refer to Fortran allocation or Cactus allocations here?
Cactus allocations. Variables for which no STORAGE statement is active (either global or in the schedule item).
The reason is that (see configs/*/bindings/include/cctk_Arguments.h) you cannot legally pass a NULL pointer as a FORTRAN array subroutine argument, there apparently *has* to be some storage (I guess FORTRAN does no allow zero-sized arrays). So for non-debug runs Cactus passes in the address of a dummy array. This is sufficient to prevent segfaults (even for rather larger grids). Caught me recently when adding the Multipatch hacks to support non-multipatch runs. I was counting on segfaults if I had forgotten any pointers (and for rather large grids, so it is not just a small grid issue that goes away in production runs). I ended up unitialized memory which was mostly 0 so it did not show up in the test (since the variable without storage was kxx in Minkowski spacetime). :-(
Yours, Roland
--8<-- configs/*/bindings/include/cctk_Arguments.h --8<-- /* * References to non-existing or non-allocated variables should be passed * as NULL pointers in order to catch any invalid access immediately * However, this runtime debugging feature may cause problems * with some fortran compilers which require all fortran routine arguments * to refer to a valid memory location (eg. to enable the code optimizer * to generate conditional load/store instructions if applicable). * For this reason, we pass NULL pointers only for debugging configurations, * and a pointer to a user-accessable memory location (a local dummy variable) * otherwise. */ --8<--
-- 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
-- Erik Schnetter schnetter@cct.lsu.edu http://www.cct.lsu.edu/~eschnett/
I don't see why we can't run both with and without debug. Both will detect different sorts of errors.
I wonder if it makes sense to have a series of short tests that run under valgrind.
Cheers, Steve
On 09/26/2011 02:42 PM, Erik Schnetter wrote:
When running test case, I would use a configuration as similar as possible to production runs, so that errors in production runs are actually caught. There are some differences between debug and optimized configurations, and these are mostly to help people track down problems, not to ensure that optimized configurations are correct. I would thus suggest that running test cases with an optimized configuration is a must, and with a debug configuration is a nice addition.
For example, sometimes code is #ifdef'd out in optimized runs, leading to undefined variables that are well defined when debugging. Another example is vectorization that is (by default) disabled without optimization, because without optimization, compilers often do a really lousy job, and vectorized code thus runs a few times slower than unvectorized code.
Regarding segfaults in Fortran: why don't unallocated variables lead to an error in Fortran? Do you refer to Fortran allocation or Cactus allocations here?
-erik
On Mon, Sep 26, 2011 at 1:20 PM, Roland Haas roland.haas@physics.gatech.edu wrote:
Hello all,
- run testsuites for release:
It might be a good idea to configure the testsuite configurations with DEBUG=yes to catch as many errors as possible (in particular for the daily testsuite runs). Otherwise eg. variables without storage can remain unnoticed under Fortran (while they casue an immediate segfault under C).
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 26 Sep 2011, at 23:42, Steven R. Brandt wrote:
I don't see why we can't run both with and without debug. Both will detect different sorts of errors.
It's question of time. We are already running all the tests on 1 proc and 2 procs, on different numbers of openmp threads (I think), on different machines. To add an additional dimension to the parameter space, even if it only of size 2, makes for a lot more work.
I wonder if it makes sense to have a series of short tests that run under valgrind.
Cheers, Steve
On 09/26/2011 02:42 PM, Erik Schnetter wrote:
When running test case, I would use a configuration as similar as possible to production runs, so that errors in production runs are actually caught. There are some differences between debug and optimized configurations, and these are mostly to help people track down problems, not to ensure that optimized configurations are correct. I would thus suggest that running test cases with an optimized configuration is a must, and with a debug configuration is a nice addition.
For example, sometimes code is #ifdef'd out in optimized runs, leading to undefined variables that are well defined when debugging. Another example is vectorization that is (by default) disabled without optimization, because without optimization, compilers often do a really lousy job, and vectorized code thus runs a few times slower than unvectorized code.
Regarding segfaults in Fortran: why don't unallocated variables lead to an error in Fortran? Do you refer to Fortran allocation or Cactus allocations here?
-erik
On Mon, Sep 26, 2011 at 1:20 PM, Roland Haas roland.haas@physics.gatech.edu wrote:
Hello all,
- run testsuites for release:
It might be a good idea to configure the testsuite configurations with DEBUG=yes to catch as many errors as possible (in particular for the daily testsuite runs). Otherwise eg. variables without storage can remain unnoticed under Fortran (while they casue an immediate segfault under C).
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
The best way to sample a high-dimensional parameter space is via random sampling. We could run the test cases thrice on each system, choosing a random variation each time.
-erik
On Mon, Sep 26, 2011 at 5:49 PM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 26 Sep 2011, at 23:42, Steven R. Brandt wrote:
I don't see why we can't run both with and without debug. Both will detect different sorts of errors.
It's question of time. We are already running all the tests on 1 proc and 2 procs, on different numbers of openmp threads (I think), on different machines. To add an additional dimension to the parameter space, even if it only of size 2, makes for a lot more work.
I wonder if it makes sense to have a series of short tests that run under valgrind.
Cheers, Steve
On 09/26/2011 02:42 PM, Erik Schnetter wrote:
When running test case, I would use a configuration as similar as possible to production runs, so that errors in production runs are actually caught. There are some differences between debug and optimized configurations, and these are mostly to help people track down problems, not to ensure that optimized configurations are correct. I would thus suggest that running test cases with an optimized configuration is a must, and with a debug configuration is a nice addition.
For example, sometimes code is #ifdef'd out in optimized runs, leading to undefined variables that are well defined when debugging. Another example is vectorization that is (by default) disabled without optimization, because without optimization, compilers often do a really lousy job, and vectorized code thus runs a few times slower than unvectorized code.
Regarding segfaults in Fortran: why don't unallocated variables lead to an error in Fortran? Do you refer to Fortran allocation or Cactus allocations here?
-erik
On Mon, Sep 26, 2011 at 1:20 PM, Roland Haas roland.haas@physics.gatech.edu wrote:
Hello all,
- run testsuites for release:
It might be a good idea to configure the testsuite configurations with DEBUG=yes to catch as many errors as possible (in particular for the daily testsuite runs). Otherwise eg. variables without storage can remain unnoticed under Fortran (while they casue an immediate segfault under C).
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
-- Ian Hinder ian.hinder@aei.mpg.de
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
Present were: Frank, Roland, Tanja, Peter, Yosef, Josh, Erik
ET release: * release date is three weeks from now * code is frozen, please commit not large new features unless approved by the other maintainers (in particular by Frank) * please look at remaining bugs https://trac.einsteintoolkit.org/query?status=accepted&status=assigned&a... * Carpet vectorization issue: ** Ian and Barry not present in call (holiday in Germany) ** will release code with VECTORISE=no default ** will not add in extra warning to code since it only affects one compiler and one machine * outstanding issue: update documentation for new VERBOSE option of Makefile
MHD: * now passes cylindrical blast wave test if local Lax-Friedrich flux is used in HLLE solver * patches accepted for commit before release * does not affect non-MHD tests
CCE: * Peter has data ready for commit
ET paper: * paper repository will be frozen against larger additions at 23:59 Louisiana time today * need to read though to smooth out language, check for consistent use of symbols and definitions: Frank, Josh, (Peter) * unify plots (to all use python's matplotlib): Christian, Erik, Frank (please try and see if you can convert your "own" plots based on examples and/or Christian and Franks plot scripts) * checking references: try and find a student to do so (Frank) * merge sections on spacetime evolution (matter coupling): Peter * merge relativity tools into existing sections: Peter * BBH: ** still see 8th order convergence (for any combination of 5 resolutions) when using the 4th order code ** try and understand why this the case
Yours, Roland
Roland Haas wrote:
Present were: Frank, Roland, Tanja, Peter, Yosef, Josh, Erik
and Christian
- 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.
Roland Haas wrote:
Roland Haas wrote:
Present were: Frank, Roland, Tanja, Peter, Yosef, Josh, Erik
and Christian
and Bruno.
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
Present were: Frank, Roland, Tanja, Peter, Eloisa, Bruno, Scott Hawley, Ian, Christian, Josh
Fall workshop: * last day to book hotel, those who have already booked should have received a confirmation email * will schedule pre-meeting to discuss scheduling improvements (dependency based scheduling)
ET release: * please take a look at outstanding bugs * seem to have workaround for Carpet prolongation issue * test suites: ** all (should) have trac tickets ** WeylScal4: Roland (should work, but right now only work with gcc) ** QLM: needs further debugging, Eloisa ** all cp/recovery tests need to be regenerated (change in file format) ** tovsolver: Roland * update all simfactory machine files to disable vectorization * freeze of paper by 23:59 (Lousiana time) today * Josh will read through text * Ian will expand Kranc section * Peter has tried CCE, Frank will try as well (with BHNS run)
MHD: * try to get some test suites in before release since MHD is major selling point
Yours, Roland
Hello all,
Present were: Frank, Roland, Tanja, Peter, Eloisa, Bruno, Scott Hawley, Ian, Christian, Josh
And Yosef
I have to keep better track of when people speak up so as not to forget half of the participants.
Yours, Roland
Present were: Frank, Peter, Erik, Roland, Tanja, Yosef, Bruno, Steve, Roland
Fall workshop: * there will be two separate rooms for the two sub-workshops (physics and infrastructure) * rooms are available beginning Monday morning * will run two Evo sessions, one for each room * topics: ** see wiki: https://docs.einsteintoolkit.org/et-docs/ET_Workshop_Fall_2011 ** please sign up for topics on wiki *** EOS *** MHD *** radiation transport *** generic elliptic solver *** GPU support *** improves scheduling
ET release: * please take a look at outstanding bugs * prefer workaround over complicated fix this soon before the release * test suites: ** QLM: remove complex output from test (workaround), leave ticket open ** checkpoints: regenerate (Roland) ** CarpetReduce: Tanja
ET paper: * Frank will continue with Bruno's help to unify the plots to all use matplotlib * Roland will check in unify the references * please each proofread a section of the paper * majority vote of call participants for short author list: only actual contributors to paper, rather than each code contributor. Frank will propose this to the PIs.
Yours, Roland
Present were: Frank, Peter, Roland, Yosef, Christian, Josh, Ian, Bruno, Tanja, Erik
ET release: * almost all test suites pass on almost all machines ** QLM failures likely due to tolerances ** SphericalHarmonicRecon compiler and MPI specific, only happen on non-essential machines ** Exact: suspect finite difference issues (2nd order) inside Exact, had similar problems during the last release, will not fix * remaining milestone tickets: ** Ian/Erik will write a transition guide from perl to python version of simfactory (#633) ** lonestar (645): issue is intermittend, resubmitting allows the job to start. Remove milestone. ** thornlist in tutorial (#647): tutorial will be replaced by python one, will update link at this time (Erik/Ian) ** EOS Omni transition guide (#633): is already in thorn documentation, remove milestone but leave ticket open to expand the guide. * PDF docuementation builds, HTML is still believe to not build. Ian will try again and upload a copy of the html docs once they compile * mention MHD support in GRHydro release notes * Roland will work through the tutorial once all branches are created and the thornlist updated * re-run release branch test suites on some machine to make sure there is not typo * offer prominent download link (and tarball?) on ET start page * will release tomorrow (Tuesday Oct. 25th 2011)
ET paper: * cite MHD paper as "in preparation" instead of stating that MHD has not yet been released * tov collapse: look at point halfway between surface and centre as well, finish this during this week * fix science content by Friday * finish paper by mid November * Josh will give the paper a second language read-through after Thursday
Yours, Roland
Hi,
On Mon, 24 Oct 2011, Roland Haas wrote:
Present were: Frank, Peter, Roland, Yosef, Christian, Josh, Ian, Bruno, Tanja, Erik
ET release:
- almost all test suites pass on almost all machines
** QLM failures likely due to tolerances
Correction. The QLM failures on Pandora is due to the compiler generating illegal instructions causing the test to fail without generating output.
** SphericalHarmonicRecon compiler and MPI specific, only happen on non-essential machines ** Exact: suspect finite difference issues (2nd order) inside Exact, had similar problems during the last release, will not fix
- remaining milestone tickets:
** Ian/Erik will write a transition guide from perl to python version of simfactory (#633) ** lonestar (645): issue is intermittend, resubmitting allows the job to start. Remove milestone. ** thornlist in tutorial (#647): tutorial will be replaced by python one, will update link at this time (Erik/Ian) ** EOS Omni transition guide (#633): is already in thorn documentation, remove milestone but leave ticket open to expand the guide.
- PDF docuementation builds, HTML is still believe to not build. Ian
will try again and upload a copy of the html docs once they compile
- mention MHD support in GRHydro release notes
- Roland will work through the tutorial once all branches are created
and the thornlist updated
- re-run release branch test suites on some machine to make sure there
is not typo
- offer prominent download link (and tarball?) on ET start page
- will release tomorrow (Tuesday Oct. 25th 2011)
ET paper:
- cite MHD paper as "in preparation" instead of stating that MHD has not
yet been released
- tov collapse: look at point halfway between surface and centre as
well, finish this during this week
- fix science content by Friday
- finish paper by mid November
- Josh will give the paper a second language read-through after Thursday
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.
Cheers,
Peter
On 24 Oct 2011, at 18:16, Roland Haas wrote:
- PDF docuementation builds, HTML is still believe to not build. Ian
will try again and upload a copy of the html docs once they compile
Barry and I have fixed the HTML documentation which should now build (make AllDocHTML and make ThornGuideHTML). I have updated the documentation at http://einsteintoolkit.org/documentation so this documentation now corresponds to what will be released.
Hello all,
- Roland will work through the tutorial once all branches are created
and the thornlist updated
Done. Everything seems to work now.
Yours, Roland
Hello all,
present were: Frank, Roland, Tanja, Christian, Eloisa, Josh, Yosef, Bruno
ET paper: * was not discussed at workshop * will submit to CQG * need to send to editor before submission so that it can be presented to editorial board * Josh has some more changes, after that Christian will read through it Frank will contact individual authors about remaining TODO's and write an abstract * Finish mid of this week (latest at end of this week). * author list: Frank Loeffler, Joshua Faber, Eloisa Bentivegna, Tanja Bode, Peter Diener, Roland Haas, Ian Hinder, Bruno C. Mundim, Christian D. Ott, Erik Schnetter, Gabrielle Allen, Manuela Campanelli, Pablo Laguna (as is currently in paper repository)
ET workshop: * Frank provided a short summary, detailed summary information can be found on the wiki: ** https://docs.einsteintoolkit.org/et-docs/ET_Workshop_Fall_2011_Summary_Cactu... ** https://docs.einsteintoolkit.org/et-docs/ET_Workshop_Fall_2011_Summary_ET ** https://docs.einsteintoolkit.org/et-docs/ET_Workshop_Fall_2011
misc: * maintainers please look at (large number) of tickets up for review * Kristen Boydstun at Caltech has written a Con2Prim routine using OpenCL which runs on a GPU and finds a 2x speedup (incl. data transfer) for about 10,000 zones and more for larger grids * will include Christian Reisswig's SphericalSlice in ET * propose to include GT's Outflow thorn in ET
MHD: * Roland implemented unigrid, cell-centered constraint transport in GRHydro (which is what WhiskyMHD uses, with help from Bruno Giacomazzo) * Tanja mostly implemented the algebraic gauge vector potential method with vector potential at the centre (also what WhiskyMHD uses), held up by EOS_Omni fixes
Yours, Roland
Hello all,
misc:
- maintainers please look at (large number) of tickets up for review
Do we have a "reviewed" state for tickets? For patches that are either in the "Please apply" or "Doesn't fix the problem/doesn't work for me." state?
It seems a number of the tickets in "review" state were actually reviewed and either say please apply or "doesn't work".
Yours, Roland
No, but we should.
-erik
On Mon, Nov 7, 2011 at 4:47 PM, Roland Haas roland.haas@physics.gatech.edu wrote:
Hello all,
misc: * maintainers please look at (large number) of tickets up for review
Do we have a "reviewed" state for tickets? For patches that are either in the "Please apply" or "Doesn't fix the problem/doesn't work for me." state?
It seems a number of the tickets in "review" state were actually reviewed and either say please apply or "doesn't work".
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
Present were: Ian, Roland, Frank, Jonah, Matt, Steve, Chrstine, Bruno, Peter
ET release: * hwloc issues were sorted out over the weekend * HDF5 thorn changes that look for architecture dependent include and lib directories will be reverted since the assume that gcc is present. * suggestion to instead modify ubuntu.cfg which is the only option list affected * Peter ran qc0 recenlty will check that the waves are correct * Ian Hinder worked on OSX option lists, synchorinizing homebrew and macports version * Kranc thorns were regenerated
Simfactory broken filesystem report: * Bruno asked about any existing code in simfactory that would work aroudn this * no such code exists * Bruno confirms that system creates symbolic links when asked for hard link
Yours, Roland
Hi Roland:
On 05/11/2015 05:26 PM, Roland Haas wrote:
Present were: Ian, Roland, Frank, Jonah, Matt, Steve, Chrstine, Bruno, Peter
ET release:
- hwloc issues were sorted out over the weekend
- HDF5 thorn changes that look for architecture dependent include and
lib directories will be reverted since the assume that gcc is present.
Actually no, that's not the problem since it checks for gcc availability. The problem is that those directories are system directories and we should not add them to the library search path when configuring a external library thorn. They should be added at the end of the linking command line, after configuration of all external libraries are finished, to avoid linking to a system library when indeed we want to link to the external library shipped with ET (or already installed elsewhere). For example we might add /usr/lib/x86_64-linux-gnu to HDF5 library search path but other system libraries might be there and then be picked against our will. Finding out the host system include and library standard directories and then adding them at the end of the compilation and linking command lines, respectively, is a solution that should be worked out after the release.
Cheers, Bruno.
Hello all,
ET release:
- hwloc issues were sorted out over the weekend
- HDF5 thorn changes that look for architecture dependent include and
lib directories will be reverted since the assume that gcc is present.
- suggestion to instead modify ubuntu.cfg which is the only option list
affected
- Peter ran qc0 recenlty will check that the waves are correct
- Ian Hinder worked on OSX option lists, synchorinizing homebrew and
macports version
- Kranc thorns were regenerated
Frank: best to give it a bit more time before you create the release branches for simfactory. Ubuntu.cfg as in master currently does not compile for me on a freshly installed 14.04 virtual machine if I install only the packages listed at the top (assuming the following packages are installed) in the cfg file. Basically setting HDF5_DIR=/usr fails to compile since the list does not include libhdf5-dev. Since libhdf5-dev will fail b/c it will not find the architecture dependent files (and there are actually possible conflicts between libdhf5-dev and eg petsc-dev) I took out the HDF5_DIR line which will make it compile if detection fails.
The alternative is to move libhdf5-dev into the required packages list, add the /usr/lib/x86_64-linux-gnu/hdf5/serial/lib/ to LIBDIRS, /usr/lib/x86_64-linux-gnu/hdf5/serial/include to SYS_INC_DIRS and check that that still compiles. I will try this as well once the one compiling HDF5 finishes (so that the list of packages that is supposed to make things faster also works).
I case someone wants to help PLEASE try this on a freshly installed Ubuntu 14.04 (virtual) machine. Do not try this only on your own personal workstation/laptop.
In any case, a test compilation is still ongoing and given how long this takes in a VM this may take a while.
Yours, Roland
On Tue, May 12, 2015 at 04:53:14PM +0200, Roland Haas wrote:
compile since the list does not include libhdf5-dev. Since libhdf5-dev will fail b/c it will not find the architecture dependent files (and there are actually possible conflicts between libdhf5-dev and eg petsc-dev) I took out the HDF5_DIR line which will make it compile if detection fails.
The alternative is to move libhdf5-dev into the required packages list, add the /usr/lib/x86_64-linux-gnu/hdf5/serial/lib/ to LIBDIRS, /usr/lib/x86_64-linux-gnu/hdf5/serial/include to SYS_INC_DIRS and check that that still compiles. I will try this as well once the one compiling HDF5 finishes (so that the list of packages that is supposed to make things faster also works).
I have now seen a similar issue on Debian Jessie. Ideally, the HDF5 thorn should make use of pkg-config (if available), which would take care of all of that, but this is something we can defer to after the release. For Debian Jessie this means that HDF5 will be compiled. I am not happy about that, but completely rewriting the logic in the thorn (and possibly others too because of multi-arch) is something best left to after the release.
Frank
On Tue, May 12, 2015 at 04:53:14PM +0200, Roland Haas wrote:
Frank: best to give it a bit more time before you create the release branches for simfactory. Ubuntu.cfg as in master currently does not compile for me on a freshly installed 14.04 virtual machine if I install only the packages listed at the top (assuming the following packages are installed) in the cfg file.
I'll wait until Ubuntu compiles. It does not necessarily need to be able to use the system libraries, but it needs to work both when they are installed (but not necessarily configured to be used), and when they are not.
Frank
On 12 May 2015, at 17:23, Frank Loeffler knarf@cct.lsu.edu wrote:
On Tue, May 12, 2015 at 04:53:14PM +0200, Roland Haas wrote:
Frank: best to give it a bit more time before you create the release branches for simfactory. Ubuntu.cfg as in master currently does not compile for me on a freshly installed 14.04 virtual machine if I install only the packages listed at the top (assuming the following packages are installed) in the cfg file.
I'll wait until Ubuntu compiles. It does not necessarily need to be able to use the system libraries, but it needs to work both when they are installed (but not necessarily configured to be used), and when they are not.
Mac OS with homebrew also has some problems. OpenMPI 1.8.5 was just released (6th May), and Homebrew is using it, since it is the latest version. There is a problem with huge memory leaks in the orterun process: (https://github.com/open-mpi/ompi/issues/579). For the tests, this means that the memspeed test can take down the machine, and I assume trying to use cactus for anything serious will also not be possible.
I'm testing now to see if we can compile OpenMPI from the external library, and Barry is seeing if it's possible to ask for the previous version of OpenMPI from Homebrew, which he has verified doesn't have the problem.
MacPorts doesn't have this issue as it is using 1.7.5, which is well-established.
On 12 May 2015, at 18:09, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 12 May 2015, at 17:23, Frank Loeffler knarf@cct.lsu.edu wrote:
On Tue, May 12, 2015 at 04:53:14PM +0200, Roland Haas wrote:
Frank: best to give it a bit more time before you create the release branches for simfactory. Ubuntu.cfg as in master currently does not compile for me on a freshly installed 14.04 virtual machine if I install only the packages listed at the top (assuming the following packages are installed) in the cfg file.
I'll wait until Ubuntu compiles. It does not necessarily need to be able to use the system libraries, but it needs to work both when they are installed (but not necessarily configured to be used), and when they are not.
Mac OS with homebrew also has some problems. OpenMPI 1.8.5 was just released (6th May), and Homebrew is using it, since it is the latest version. There is a problem with huge memory leaks in the orterun process: (https://github.com/open-mpi/ompi/issues/579). For the tests, this means that the memspeed test can take down the machine, and I assume trying to use cactus for anything serious will also not be possible.
I'm testing now to see if we can compile OpenMPI from the external library, and Barry is seeing if it's possible to ask for the previous version of OpenMPI from Homebrew, which he has verified doesn't have the problem.
MacPorts doesn't have this issue as it is using 1.7.5, which is well-established.
Barry has updated the homebrew optionlist and runscript to use OpenMPI 1.6, and the problem no longer occurs. Erik tidied up some settings in both homebrew and macports optionlists, including adding -Ofast for performance, which causes the LocalInterp2 test to fail (see other thread), but this just makes it consistent with other machines, where value-unsafe optimisations are used anyway. From the point of view of Mac OS, there is nothing more holding up the release.
On Wed, May 13, 2015 at 10:42 AM, Ian Hinder ian.hinder@aei.mpg.de wrote:
Barry has updated the homebrew optionlist and runscript to use OpenMPI 1.6, and the problem no longer occurs.
The problematic version of OpenMPI (1.8.5) has been blocked by homebrew, so there is no longer a need to explicitly use 1.6. I've simplified the optionlist to just use the default homebrew version of OpenMPI and also removed the osx-homebrew runscript since generic-mpi is now sufficient.
Hello all,
I case someone wants to help PLEASE try this on a freshly installed Ubuntu 14.04 (virtual) machine. Do not try this only on your own personal workstation/laptop.
I pushed a version of ubuntu.cfg that lets me compile and run the tests on a stock 14.04 system installing only the packages listed at the very top (build-essential gcc g++ gfortran mpich2 libmpich2?-devel).
I am compiling with the extended list of packages (no boost since the package listed does not exist in 14.04) to see if this also succeeds. Note that this may *still* build some packages even though development files for them are installed since the auto-detect will fail due to multi-arch directories.
This can be added after the release though.
Yours, Roland
users@lists.einsteintoolkit.org
-
Barry Wardell -
Bruno Coutinho Mundim -
Erik Schnetter -
Frank Loeffler -
Ian Hinder -
Peter Diener -
Roland Haas -
Roland Haas -
Roland Haas -
Steven R. Brandt