#1658: ExternalLibraries/pciutils does not compile on Mac OS
--------------------+-------------------------------------------------------
Reporter: hinder | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Cactus | Version: development version
Keywords: |
--------------------+-------------------------------------------------------
When I try to compile ExternalLibraries/pciutils on Mac OS, I get
{{{
lspci.c:919:29: error: expected ')'
puts("lspci version " PCIUTILS_VERSION);
^
./pciutils.h:18:26: note: expanded from macro 'PCIUTILS_VERSION'
#define PCIUTILS_VERSION PCILIB_VERSION
^
lspci.c:919:11: note: to match this '('
puts("lspci version " PCIUTILS_VERSION);
}}}
This is with the osx-mountain-lion-macports-gcc.cfg optionlist, and "gcc-
mp-4.6 (MacPorts gcc46 4.6.4_3) 4.6.4".
I have to disable this thorn in my thornlist (or machine definition file)
to compile the ET. This means that the ET will not compile out of the box
on Mac OS.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1658>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1934: pciutils was broken
----------------------+-----------------------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: unset | Milestone:
Component: Other | Version: development version
Keywords: |
----------------------+-----------------------------------------------------
ExternalLibraries/pciutils was broken; the configure.sh script references
two patch files that were not there. I reverted the commit.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1934>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1906: CarpetRegrid2: possible off-by-one error when using regrid_every parameter
---------------------------+------------------------------------------------
Reporter: bmundim | Owner: eschnett
Type: defect | Status: new
Priority: major | Milestone:
Component: Carpet | Version: development version
Keywords: CarpetRegrid2 |
---------------------------+------------------------------------------------
I was working on a par file for a quick regridding test and found out an
unexpected behaviour regarding regridding. Basically I want a par file
with a few iterations such that it adds a refinement level every 4
iterations for example. I set the following parameters then:
{{{
CarpetRegrid2::add_levels_automatically = "yes"
CarpetRegrid2::regrid_every = 4
}}}
for a grid structure as such:
{{{
Cactus::cctk_itlast = 10
CoordBase::xmin = -0.5
CoordBase::ymin = -0.5
CoordBase::zmin = -0.5
CoordBase::xmax = 0.5
CoordBase::ymax = 0.5
CoordBase::zmax = 0.5
CoordBase::ncells_x = 16
CoordBase::ncells_y = 16
CoordBase::ncells_z = 16
Carpet::max_refinement_levels = 3
CarpetRegrid2::num_centres = 1
CarpetRegrid2::active_1 = "yes"
CarpetRegrid2::num_levels_1 = 1
CarpetRegrid2::radius_1[1] = 0.12
CarpetRegrid2::radius_1[2] = 0.04
}}}
I was expecting then regridding to happen at iterations 4 and 8, however
if you run the attached par file, a modification of balsara shocktube
test, you see that the level additions actually happen at iterations 5 and
9 instead:
{{{
...
INFO (CarpetRegrid2): Increasing number of levels of centre 1 to 2 (it=5)
...
INFO (CarpetRegrid2): Increasing number of levels of centre 1 to 3 (it=9)
}}}
which is apparently an off-by-one kind of error. I tracked down the code
producing these messages and it comes from function
CarpetRegrid2_RegridMaps at CarpetRegrid2/src/regrid.cc, lines 745 to 747.
In order for that piece of code to execute we do have to have do_recompose
set to true. Strangely the condition to set it, compares the previous
iteration to the regrid_every parameter on line 707 of the same file:
{{{
(cctk_iteration - 1) % regrid_every == 0
}}}
Investigating if this actually makes sense I was led to what I think it
might be the source of the problem on line 58 of Carpet/src/Evolve.cc.
Time and iteration is advanced before calling CallRegrid. Skimming over
the AdvanceTime routine it is not clear to me that it really needs to be
called before CallRegrid. If it is really needed then why the condition to
regrid or not is not taken on the current updated iteration as in:
{{{
cctk_iteration % regrid_every == 0
}}}
Thanks,
Bruno
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1906>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1778: Scheduling WHILE Loops in CCTK_ANALYSIS Results in Hang
--------------------------------+-------------------------------------------
Reporter: zachetie@… | Owner:
Type: defect | Status: new
Priority: unset | Milestone:
Component: Other | Version: ET_2015_05
Keywords: |
--------------------------------+-------------------------------------------
When encountering a WHILE loop inside CCTK_ANALYSIS, Cactus simply hangs.
I have created a simple thorn, ScheduleTester, that reproduces this
problem 100% of the time. The thorn only takes as input the number of
iterations desired in the WHILE loop. I have attached this thorn, as well
as example .par and ThornList files to this ticket.
This problem is verified to exist within 2015_05 as well as 2014_11 ET
releases. I have not tried past releases.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1778>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1992: provide bibtext snippets for requested cittations on ET website
----------------------------+-----------------------------------------------
Reporter: rhaas | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus website | Version: development version
Keywords: |
----------------------------+-----------------------------------------------
Our citing page http://einsteintoolkit.org/documentation/licenses/ right
now lists the bibtex key and the doi for the requested citations. It would
be useful to make the bibtex keys hyperlinks to a bibtex fragment for the
paper in question that could be copied and pasted into a user's bibtext
file. If we don't want to use the fragment from our own
einsteintoolkit.bib we could use INSPIRE's doe search facility using
"bibtex" as the output format, eg:
http://inspirehep.net/search?ln=en&ln=en&p=doi%3A10.1088%2F0264-9381%2F21%2…
for the Carpet reference.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1992>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#2025: ssl warning for wiki.einsteintoolkit.org
-------------------------------------+--------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit website | Version: development version
Keywords: |
-------------------------------------+--------------------------------------
My browser (Firefox 45.8.0 ESR) reports
{{{
wiki.einsteintoolkit.org uses an invalid security certificate. The
certificate is only valid for wiki.cct.lsu.edu Error code:
SSL_ERROR_BAD_CERT_DOMAIN
}}}
for https://wiki.einsteintoolkit.org/
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/2025>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#502: SimFactory user-guide should be available and updated automatically
-------------------------+--------------------------------------------------
Reporter: hinder | Owner: knarf
Type: enhancement | Status: new
Priority: major | Milestone:
Component: SimFactory | Version:
Keywords: |
-------------------------+--------------------------------------------------
SimFactory has an incomplete user guide in the doc/userguide directory.
This is developed using Sphinx, which is a Python framework for writing
documentation. You need to install sphinx to generate this documentation.
This can be done using something similar to the following:
export PYTHONPATH=/home/ianhin/software/python
export PATH=/home/ianhin/software/python/:$PATH
hash -r
easy_install --install-dir ~/software/python sphinx
Then go into the simfactory/doc/userguide directory and type:
./autogen
make html
to generate HTML documentation (type just "make" to see the other possible
targets like PDF etc).
This should be regenerated on any commit to the SimFactory/doc/userguide
directory and copied to a web-accessible location for inclusion on
simfactory.org.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/502>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1698: The ET tickets should be tidied up
----------------------------------+-----------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit trac | Version: development version
Keywords: |
----------------------------------+-----------------------------------------
Many of the ET tickets have not seen much attention recently or at all.
We should have a session where we run though all the tickets and make sure
that their priorities/state etc are correct. Once we have done this, we
should come up with a strategy for keeping the tickets under control. In
the process, we should decide what is meant by the different ticket
priorities, and whether we need to add additional priorities or states to
allow us to more effectively manage the tickets.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1698>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#719: Mailing lists could have a link to the archived version of the message
-------------------------+--------------------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Other | Version:
Keywords: |
-------------------------+--------------------------------------------------
It would be useful for the footer of a mailing list posting to contain a
URL to the archived version of the message so that it is easy to point
people to the message in an email. This would apply to both the Cactus
and the ET lists.
It appears that this is not straightforward in MailMan 2, but is expected
in version 3: http://mail.python.org/pipermail/mailman-
users/2011-October/072378.html.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/719>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit