#304: SimFactory should not clean-up so aggressively
------------------------+---------------------------------------------------
Reporter: hinder | Owner: mthomas
Type: defect | Status: new
Priority: major | Milestone:
Component: SimFactory | Version:
Keywords: |
------------------------+---------------------------------------------------
As far as I can tell, SimFactory 2 currently cleans up all simulations
every time it is run. This is not scalable - if you are running with a
slow production filesystem, just statting all the simulations could take a
very long time. Similarly, if you do a sim sync, it currently cleans up
all the simulations on your local machine, as well as the remote machine.
Running sim --help even cleans up all your simulations!
This behaviour is very counter-intuitive (certainly not what a user would
expect) and not suitable for production systems. I propose that
simfactory should only clean up the simulation which is being referred to
in the current command.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/304>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#328: TRAC frequently logs users out
----------------------------------+-----------------------------------------
Reporter: hinder | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit trac | Version:
Keywords: |
----------------------------------+-----------------------------------------
There seems to be some mechanism which is automatically logging users out
of TRAC. This means that they end up posting as "anonymous" because they
don't realise they are logged out. Probably there is a session cookie
which expires or something.
To avoid this, we could either try to change the logout (I would be happy
if the automatic logout was just disabled completely), or make it much
more obvious when you are not logged in.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/328>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#385: No link to wiki
-------------------------------------+--------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit website | Version:
Keywords: |
-------------------------------------+--------------------------------------
There is no (obvious) link to the wiki on the Einstein Toolkit web site.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/385>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#348: https://docs.einsteintoolkit.org/ does not redirect to the docs page
-------------------------------------+--------------------------------------
Reporter: hinder | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit website | Version:
Keywords: docs |
-------------------------------------+--------------------------------------
When I go to
https://docs.einsteintoolkit.org/
it takes me to the list of CCT wikis. Based on the hostname, it should
redirect to the correct page automatically.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/348>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#375: RotatingSymmetry*: Improve performance
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
The attached patches depend on the new Slab API provided by ticket #374:
Use the new Slab API to set up the communication schedule only once (per
regridding), which saves some communication time when applying symmetries.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/375>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#374: CactusNumeric/Slab: Improve performance
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
The attached patch does the following, prompted by performance problems
reported by Christian Ott:
Reorganise some of the internals of thorn Slab:
Use LoopControl to parallelise loops via OpenMP.
Refactor the "work horse" routines that perform the actual copy routines.
These routines are specialised for common cases that need to execute
efficiently, in particular for the cases encountered in RotatingSymmetry90
and RotatingSymmetry180 when handling CCTK_REAL variables.
Offer an additional API (Slab_MultiTransfer_Init,
Slab_MultiTransfer_Apply, Slab_MultiTransfer_Finalize) that calculates the
communication schedule only once, and then re-uses it in further calls.
This avoids some communication overhead.
Remove old CVS header comments.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/374>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#422: Cactus make problems
----------------------------------------------+-----------------------------
Reporter: alexander.beck-ratzka@… | Type: defect
Status: new | Priority: major
Milestone: | Component: Cactus
Version: | Keywords:
----------------------------------------------+-----------------------------
I have a make problem with ther new cactus revision. Make fails with the
error:
[snip]
Checking status of thorn CarpetControl
________________________________________________________________________
Preprocessing /home/alibeck/programme/Cactus-
Luca/Cactus/arrangements/Whisky_Exp/CarpetControl/src/CarpetControl.cc
Compiling /home/alibeck/programme/Cactus-
Luca/Cactus/arrangements/Whisky_Exp/CarpetControl/src/CarpetControl.cc
/home/alibeck/programme/Cactus-
Luca/Cactus/arrangements/Whisky_Exp/CarpetControl/src/CarpetControl.cc(20):
error: cannot overload functions distinguished by return type alone
void CarpetControl_Initialize(void)
^
compilation aborted for /home/alibeck/programme/Cactus-Luca/Cactus/configs
/carpet-luca-cactus-new-cactus/build/CarpetControl/CarpetControl.cc (code
2)
make[3]: *** [CarpetControl.cc.o] Error 2
make[2]: *** [make.checked] Error 2
make[1]: *** [/home/alibeck/programme/Cactus-Luca/Cactus/configs/carpet-
luca-cactus-new-cactus/lib/libthorn_CarpetControl.a] Error 2
make: *** [carpet-luca-cactus-new-cactus] Error 2
[snip]
The make dost not fail using the revision r4620
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/422>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#383: SimFactory 1 does not create source directory on login
------------------------+---------------------------------------------------
Reporter: hinder | Owner: mthomas
Type: defect | Status: new
Priority: major | Milestone: ET_2011_05
Component: SimFactory | Version:
Keywords: |
------------------------+---------------------------------------------------
If I run "sim login <machine>" to a machine where the remote source
directory does not exist, the login fails with
bash: line 0: cd: /nics/d/home/hinder/Cactus/etrelease: No such file or
directory
Connection to kraken-gsi2.nics.teragrid.org closed.
If I run a "sim sync" first, then a subsequent sim login works correctly.
I propose that simfactory should create the required directories before
logging in.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/383>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#242: build fails after running out of disk space
------------------------+---------------------------------------------------
Reporter: eschnett | Owner: mthomas
Type: defect | Status: new
Priority: major | Milestone:
Component: SimFactory | Version:
Keywords: |
------------------------+---------------------------------------------------
After running out of disk space (and then removing 16 GByte), building
fails on numrel09:
$ ./bin/sim build
DEBUG: Simfactory command: ./bin/../simfactory/lib/sim.py "build"
DEBUG: Version exported
The Simulation Factory: Manage Cactus simulations
Info: defs: /home/eschnett/EinsteinToolkit-hg-
vanilla/simfactory/etc/defs.ini
Info: defs.local: /home/eschnett/EinsteinToolkit-hg-
vanilla/simfactory/etc/defs.local.ini
Info: Executing command: build
Using configuration: sim
Info: Cactus Directory: /home/eschnett/EinsteinToolkit-hg-vanilla
Traceback (most recent call last):
File "./bin/../simfactory/lib/sim.py", line 142, in <module>
main()
File "./bin/../simfactory/lib/sim.py", line 139, in main
CommandDispatch()
File "./bin/../simfactory/lib/sim.py", line 106, in CommandDispatch
module.main()
File "/home/eschnett/EinsteinToolkit-hg-vanilla/simfactory/lib/sim-
build.py", line 420, in main
CommandDispatch()
File "/home/eschnett/EinsteinToolkit-hg-vanilla/simfactory/lib/sim-
build.py", line 347, in CommandDispatch
exec("command_%s()" % command)
File "<string>", line 1, in <module>
File "/home/eschnett/EinsteinToolkit-hg-vanilla/simfactory/lib/sim-
build.py", line 391, in command_build
PrepConfiguration(config)
File "/home/eschnett/EinsteinToolkit-hg-vanilla/simfactory/lib/sim-
build.py", line 58, in PrepConfiguration
prop.init(propertiesFile)
File "/home/eschnett/EinsteinToolkit-hg-
vanilla/simfactory/lib/restartlib.py", line 101, in init
self.ImportProperties()
File "/home/eschnett/EinsteinToolkit-hg-
vanilla/simfactory/lib/restartlib.py", line 107, in ImportProperties
for key in section.keys():
AttributeError: 'NoneType' object has no attribute 'keys'
This looks as if some internal information about the build has become
corrupt, maybe because of a partially written file.
This may be a rare case not worth handling elegantly. However -- what
should I do now?
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/242>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#363: Make TimerReport output average/min/max timings to stdout, instead of
timings from the root process
----------------------+-----------------------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Cactus | Version:
Keywords: |
----------------------+-----------------------------------------------------
The n_top_timers feature of TimerReport outputs timings from the root
process only to stdout, greatly confusing people. It should instead output
average (or min/max) timings over all processes.
One common problem is a routine that contains communication, and which
thus has to wait until all processes arrive there. If previous routines
show a load imbalance, then outputting timings only from the root process
make this routine look very slow, although this routine really only has to
wait for other processes finish their previous calculations. Since this is
a common case, it makes the current timing output useless for all routines
involving communication.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/363>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit