#1001: Distinguish between local and global reduction handles
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
Local and global reduction handles both use small integers. This means
that code may accidentally confuse one for the other.
To avoid this, we could add large, different offsets for local and global
handles, so that they would be different. We already do this for other
integer IDs in the flesh.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1001>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#999: .....
--------------------------------------+-------------------------------------
Reporter: permeduclo1976@… | Type: defect
Status: new | Priority: major
Milestone: | Component: Other
Version: | Keywords: key1,key2
--------------------------------------+-------------------------------------
_, I like this site very much so much fantastic info .
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/999>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#991: PITTNullCode updates
-----------------------------------+----------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: PITTNull code |
-----------------------------------+----------------------------------------
These patches contain three types of updates (sorry, I do not have feature
separated ones):
* making parameters steerable
* respecting the truncate_files Cactus Parameter
* a bugfix where points that were interpolated very close to the
extraction world tube had very low accuracy due to a hard-coded offset
(Nick Taylor and Bela Szilagyi found and fixed this)
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/991>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#993: simfactory rev 1729 fails on lonestar
------------------------+---------------------------------------------------
Reporter: rhaas | Owner: eschnett
Type: defect | Status: new
Priority: major | Milestone:
Component: SimFactory | Version:
Keywords: |
------------------------+---------------------------------------------------
Hello all,
simfactory rev 1729 "Replace large files by hard links during cleanup"
fails for me during submit on lonestar with:
{{{
Traceback (most recent call last):
File "/work/00945/rhaas/Zelmani/simfactory/bin/../lib/sim.py", line 147,
in ?
main()
File "/work/00945/rhaas/Zelmani/simfactory/bin/../lib/sim.py", line 143,
in main
CommandDispatch()
File "/work/00945/rhaas/Zelmani/simfactory/bin/../lib/sim.py", line 105,
in CommandDispatch
module.main()
File "/work/00945/rhaas/Zelmani/simfactory/lib/sim-manage.py", line 397,
in main
CommandDispatch()
File "/work/00945/rhaas/Zelmani/simfactory/lib/sim-manage.py", line 376,
in CommandDispatch
exec("command_%s()" % command)
File "<string>", line 1, in ?
File "/work/00945/rhaas/Zelmani/simfactory/lib/sim-manage.py", line 213,
in command_run
restart.submitRun(simulationName, restart_id)
File "/work/00945/rhaas/Zelmani/simfactory/lib/simrestart.py", line 952,
in submitRun
restart.finish()
File "/work/00945/rhaas/Zelmani/simfactory/lib/simrestart.py", line
1629, in finish
if not filecmp.cmp(path, oldpath, False):
NameError: global name 'filecmp' is not defined
}}}
when it tries to execute:
{{{
/work/00945/rhaas/Zelmani/simfactory/bin/sim run sim --machine=lonestar
--restart-id=13 --from-restart-id=12
}}}
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/993>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#992: Support Darwin 12.0.0
---------------------------+------------------------------------------------
Reporter: barry.wardell | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Other | Version:
Keywords: |
---------------------------+------------------------------------------------
The attached patch adds Darwin 12.0.0 to the list of known architectures.
This is the kernel version included with OS X 10.8.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/992>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#985: add OPTIONAL dependency on MPI to HDF5
-----------------------------------+----------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: HDF5 |
-----------------------------------+----------------------------------------
With #980 thorns using a compiled HDF5 version that has parallel MPI
enabled (such as the the one on my debian system which I need because
either PetSC or libsiloh5 wanted it) do not compile anymore. Adding
{{{
OPTIONAL HDF5
{
}
}}}
to ExternalLibraries/HDF5's confguration.ccl fixes this. Ok to apply?
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/985>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#976: Cactus ignors (since r4839 ie #768) changes to param.ccl when recompiling
----------------------+-----------------------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: critical | Milestone:
Component: Cactus | Version:
Keywords: |
----------------------+-----------------------------------------------------
Christian Reisswig (and I and Christian Ott and Philipp Moesta, but we did
not properly identify it as a bug) found that adding or removing a
parameter does not trigger a recompile of source files where the parameter
was used. To reproduce, take a compiled configuration and eg. comment out
a parameter in (any) thorn's param.ccl. Recompile and notice that no
source files are recompiled (but
configs/<CONFIG>/bindings/Parameters/<Thorn>_Parameters.c is). This
manifests itself in wrong parameter values in the thorns (but correct
values as returned by CCTK_ParameterGet).
I checked and the file containing the updated parameter structure
(configs/<CONFIGNAME>/bindings/include/ParameterCPrivate<THORNNAME>.h)
'''does''' appear in the source file's auto-dependency file
(configs/<CONFIGNAME>/build/<THORNNAME>/<SOURCEFILE>.c.d) but that files
seems to be completely ignored (ie. touch'ing a file listed in there does
not trigger a recompile).
I am making this a critical bug since it affects every single thorn.
I attach a trivial thorn to display the issue but any configuration you
have sitting around will do.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/976>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#987: Support Darwin 11.4.2
---------------------------+------------------------------------------------
Reporter: barry.wardell | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Cactus | Version:
Keywords: |
---------------------------+------------------------------------------------
The attached patch adds Darwin 11.4.2 to the list of known architectures.
This is the kernel version included with the Retina MacBook Pro running
OSX 10.7.4.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/987>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#986: PETSc configuration on ranger doesn't find BLAS/LAPACK
-----------------------------------+----------------------------------------
Reporter: bmundim | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: PETSc ranger |
-----------------------------------+----------------------------------------
Hi,
when building PETSc on ranger with simfactory options ranger-intel11.cfg
slightly
modified to install PETSc on a user defined directory (PETSC_INSTALL_DIR
set), there
is a complain during configuration phase about not finding BLAS/LAPACK:
PETSc: Configuring...
PETSc: Could not find BLAS library -mkl
PETSc: Could not find LAPACK library -mkl
At the end, the library seems to be compiled though. I am just wondering
if it was
linked or not to lapack/blas at some later stage by some other Cactus
mechanism.
Can someone with more experience with this library shed some light?
Thanks!
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/986>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#989: Carpet should allocate multiple cGH structures, one for each component
-------------------------+--------------------------------------------------
Reporter: hinder | Owner: eschnett
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Carpet | Version:
Keywords: |
-------------------------+--------------------------------------------------
Carpet should allocate multiple cGH structures, one for each component.
This avoid having to repopulate a cGH structure, which might be expensive
when mode switching.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/989>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit