#1359: add "read from file" option ot HydroBase's initial_data options
-----------------------------------+----------------------------------------
Reporter: rhaas | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: HydroBase |
-----------------------------------+----------------------------------------
the attached patch adds a value "read from file" to HydroBase's
initial_XXX options. This makes it possible to use IOUtils file reader
with hydro data.
This is somewhat similar to IDFileADM's extension of ADMBase's options,
only we do not have to set any grid scalars.
Needed to be able to reproduce the MHD paper's collapse test since
Whisky_RNSID is not public.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1359>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1215: Source browsing not working
----------------------------------+-----------------------------------------
Reporter: hinder | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit trac | Version:
Keywords: |
----------------------------------+-----------------------------------------
The repositories in the "Browse source" TRAC interface
(https://trac.einsteintoolkit.org/browser) are not being updated. The
last Cactus flesh commit visible there is from 10 months ago.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1215>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#849: Drop explicit support for Fortran 77 in Cactus
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
I suggest to drop explicit support for Fortran 77 in Cactus. Fortran 77
is, for all practical purposes, a subset of Fortran 90, and thus Fortran
77 code can be compiled by Fortran 90 compilers.
There is currently no platform that has a Fortran 77 and no Fortran 90
compiler, and there is no Fortran source code in Cactus that cannot be
compiled by a Fortran 90 compiler.
In a way, supporting Fortran 77 as language is similar to supporting K&R C
as a language. We don't do this either.
I suggest to remove/ignore all configuration options regarding Fortran 77,
and to compile .f77 and .F77 files with a Fortran 90 compiler. This change
will simplify the configuration stage of Cactus. I don't expect any user
to notice.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/849>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#882: Create ThornGuideHTML target
----------------------+-----------------------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
----------------------+-----------------------------------------------------
Barry Wardell suggests: The only issue is that there doesn't seem to be a
HTML version of the configuration specific ThornGuide make target, so we
should add this as a target at the same time as removing the patch. I'd
imagine this would just be a matter of copy-and-paste from the existing
ThornGuideHTML target.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/882>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1314: increase number of triggers in AEIThorns trigger
-----------------------------------+----------------------------------------
Reporter: rhaas | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: Trigger |
-----------------------------------+----------------------------------------
currently the max is 10. I find myself needing more (15 to be precise).
Can we increase this number to say 39 (or some other largish non-typical
number) or are that many parameters too expensive to support?
Similarly (but more complicated) it would be useful to be able to steer
more than one parameter/grid scalar when a trigger triggers. The current
way of specifying targets is unfortunately not well suited for this.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1314>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1117: Wrong CarpetIOASCII headers for complex 2D output.
----------------------------------------+-----------------------------------
Reporter: reisswig@… | Type: defect
Status: new | Priority: minor
Milestone: | Component: Other
Version: | Keywords:
----------------------------------------+-----------------------------------
I am outputting a 2d _complex_ array (called "extracted_vars") using 2d
CarpetIOASCII output.
Using the standard output format, the data starts at column 13.
So the first array element "extracted_vars[0]" is at column 13.
Now, since I have a complex array, the second element,
"extracted_vars[1]", must be at column 15 (column 14 contains the
imaginary part of element [0]). In older versions of Carpet, this was
reported correctly in the header. In the current version, it is incorrect.
The second element, "extracted_vars[1]" is reported to be in column 14
instead of 15.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1117>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#542: Remove thorn CactusArchive/ADM from thorn list
-----------------------------------+----------------------------------------
Reporter: eschnett | Owner:
Type: task | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: |
-----------------------------------+----------------------------------------
Remove thorn CactusArchive/ADM from thorn list. This thorn is outdated,
and we should updated out test cases instead. It also takes a long time
and a lot of memory to compile.
If we want an ADM formulation (which is doubtful since we don't use it
ourselves), we should implement one via Kranc.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/542>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#114: per-variable tolerances for Cactus testsuites
-------------------------+--------------------------------------------------
Reporter: knarf | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: ET_2011_06
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
It would be nice to be able to specify per-variable testsuite tolerances
in Cactus (per regexp for the name in the ideal case).
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/114>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1352: ExternalLibraries/Lua requires readline-headers
--------------------+-------------------------------------------------------
Reporter: knarf | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: Other | Version:
Keywords: |
--------------------+-------------------------------------------------------
ExternalLibraries/Lua requires readline-headers, but there is no check for
it. We could provide a thorn containing it (or forget about the lua thorn
- I don't know of any user right now).
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1352>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1381: Carpet no longer has an implied sync() call after restriction
--------------------+-------------------------------------------------------
Reporter: rhaas | Owner: eschnett
Type: defect | Status: new
Priority: minor | Milestone:
Component: Carpet | Version: development version
Keywords: |
--------------------+-------------------------------------------------------
I just pushed two tests for the higher order restriction code into
CarpetProlongateTest. What I did was to generate the test data before the
commit that removes the extra sync, then save the data and apply as the
test data on top of the master branch. I also verified that indeed I get
the same restricted data across an interprocessor boundary (ie in the z
direction of the tests).
Surprisingly I actually do since in fact the schedule.ccl file in
CarpetProlongateTest does not apply boundary conditions are SYNC in
MoL_PostStep so that I should have gotten test failures.
This would seem to indicate that either (a) I don't have my test setup
correctly (always possibly) or (b) there is yet another SYNC hidden
somewhere inside of CarpetLib/Carpet.
On the other hand, the current "_rest" tests in CarpetProlongateTest now
fail for me unless I re-add the sync. Adding a dummy routine and SYNC to
MoL_PostStep which I think is the correct thing to do does not help
possibly because the SYNC implies a prolongation while a low-level sync
call does not (and which is where I see differences). This of course would
argue against (b) above.
Attached please find my code change a a plot of diffference.z.asc for
test_cc_rest_o3 before and after the change.
I do not necessarily think that this is a bug, it certainly is unexpected
though.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1381>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit