chaste / chaste Goto Github PK
View Code? Open in Web Editor NEWChaste - Cancer Heart And Soft Tissue Environment - main public repository.
Home Page: https://chaste.github.io/
License: Other
Chaste - Cancer Heart And Soft Tissue Environment - main public repository.
Home Page: https://chaste.github.io/
License: Other
I have just picked up the issue #3092 from the old trac, replicating here to start the discussion.
VerifyStateVariables
include a not NaN / Inf check?mirams created the following ticket on 2022-03-29 at 15:49:31, it is owned by mirams
I thought that at some point the ODE solvers had a isnan(state_vars)
sort of check, but they don't seem to.
Should one be added to the VerifyStateVariables()
methods that are autogenerated by chaste_codegen ?
See also #2713 for a related VerifyStateVariables()
enhancement that might be good to do at the same time.
This issue continues the discussion for legacy trac ticket 3099:
fcooper8472 created the following ticket on 2022-05-20 at 11:11:57, it is owned by fcooper8472
Comment by kwabenantim on 2022-08-25 at 10:33:09
Portability Testing:
Comment by kwabenantim on 2022-08-25 at 13:15:46
Portability Testing:
Comment by kwabenantim on 2022-09-01 at 08:13:01
Portability Testing
My main question: how can I adjust how much memory I allow Chaste to use?
I would like to increase this amount as I have 32GB of RAM and I think Chaste kills simulations well before it uses all of what's available.
I am running some off-lattice node-based cell models.
My cell populations divide and run for some
This usually means that my simulation stop time is approximately 7 (I think the units are hours), where each cell cycle is uniform around 1.
When I try to run my simulations past 7 or so, I get errors saying my simulation threw an exception.
I am not sure how to gauge what is happening, but I wanted to start by exploring the memory case first.
Also, I have 8 cores that I can multi-thread to 16, is there any way I can parallelise multiple runs of a model?
This issue continues the discussion for legacy trac ticket 2843:
AlexFletcher created the following ticket on 2016-08-22 at 10:55:55, it is owned by AlexFletcher
It would be good to have user tutorials auto-generated from the develop branch of the git repo (cf. trac ticket 2655 and trac ticket 2656). We should also replace references to scons with the corresponding CMake commands in user tutorials and other tests.
The tests that refer to scons are:
continuum_mechanics/test/TestSolvingElasticityProblemsTutorial.hpp
crypt/test/simulation/TestArchiveFormat.hpp
global/test/TestCommandLineArguments.hpp
global/test/TestWritingTestsTutorial.hpp
heart/test/monodomain/TestMonodomainTissue.hpp
heart/test/tutorials/TestCardiacElectroMechanicsTutorial.hpp
heart/test/tutorials/TestMonodomain3dExampleTutorial.hpp
heart/test/TestCardiacSimulation.hpp
heart/test/TestCardiacSimulationArchiver.hpp
pde/test/tutorials/TestSolvingLinearPdesTutorial.hpp
This issue continues the discussion for legacy trac ticket 3053:
jmpf created the following ticket on 2020-10-22 at 11:40:57, it is owned by jmpf
Improve performance of Chaste web-server.
Most nights it's running out of memory and swapping. This is disruptive to people working in other time zones.
Comment by jmpf on 2020-10-22 at 11:48:32
Since Feb 2019 I have had the machine record its load-average and swap usage in half-hourly intervals. (See crontab for chaste@chaste.)
I have also had the machine attempt to recover swap space at 8am every morning. If the nightly backup is still going then this may fail. (See crontab for root@chaste.)
I have also produced email alerts for lack of webserver on an hourly basis. This is done using wget and looking for "Internal Server Error". (See crontab for jmpf@his-work-desktop.)
Comment by jmpf on 2020-10-22 at 11:54:37
Record of the biggest files being backed up:
405,957 21-10-2020 00:29:16 Normal File--> 405,957 /var/www/scratch/buildbot/master/public_html/Nightly Google Profile/profile1127/Test2DMeshBasedCryptRepresentativeSimulation.prof [Sent]
409,535 21-10-2020 00:29:12 Normal File--> 409,535 /var/www/scratch/buildbot/master/public_html/Nightly Coverage/coverage1174/mesh/src/vertex/MutableVertexMesh.cpp.gcov.html [Sent]
479,846 21-10-2020 00:29:17 Normal File--> 479,846 /var/www/scratch/buildbot/master/public_html/Nightly Google Profile/profile1127/Test3dBidomainProblemForEfficiencyWithFasterOdes.prof [Sent]
511,487 21-10-2020 00:29:17 Normal File--> 511,487 /var/www/scratch/buildbot/master/public_html/Nightly Google Profile/profile1127/Test3dBidomainProblemWithMetisForEfficiency.prof [Sent]
525,068 21-10-2020 00:29:17 Normal File--> 525,068 /var/www/scratch/buildbot/master/public_html/Nightly Google Profile/profile1127/Test3dBidomainProblemWithPermForEfficiency.prof [Sent]
577,478 21-10-2020 00:33:27 Normal File--> 577,478 /var/log/apache2/error.log [Sent]
964,604 21-10-2020 00:29:17 Normal File--> 964,604 /var/www/scratch/buildbot/master/public_html/Nightly Google Profile/profile1127/Test3dBidomainProblemForEfficiency.prof [Sent]
990,654 21-10-2020 00:29:18 Normal File--> 990,654 /var/www/scratch/buildbot/master/public_html/Nightly Google Profile/profile1127/Test3dOffLatticeRepresentativeSimulation.prof [Sent]
1,951,255 21-10-2020 00:29:17 Normal File--> 1,951,255 /var/www/scratch/buildbot/master/public_html/Nightly Google Profile/profile1127/Test2dVertexBasedSimulationWithFreeBoundary.prof [Sent]
2,292,032 21-10-2020 00:29:16 Normal File--> 2,292,032 /var/www/scratch/buildbot/master/public_html/Nightly Google Profile/profile1127/Test2DVertexBasedCryptRepresentativeSimulation.prof [Sent]
2,811,807 21-10-2020 00:29:18 Normal File--> 2,811,807 /var/www/scratch/buildbot/master/public_html/Nightly Google Profile/profile1127/TestLongPostprocessing.prof [Sent]
3,860,718 21-10-2020 00:32:27 Normal File--> 3,860,718 /var/lib/apt-xapian-index/cataloged_times.p [Sent]
4,730,249 21-10-2020 00:32:26 Normal File--> 4,730,249 /home/chaste/forensic [Sent]
5,242,880 21-10-2020 00:33:16 Normal File--> 5,242,880 /var/lib/mysql/ib_logfile0 [Sent]
5,242,880 21-10-2020 00:33:17 Normal File--> 5,242,880 /var/lib/mysql/ib_logfile1 [Sent]
6,141,311 21-10-2020 00:33:21 Normal File--> 6,141,311 /var/log/dsminstr.log [Sent]
14,514,672 21-10-2020 00:33:23 Normal File--> 14,514,672 /var/log/dsmsched.log Changed
20,806,656 21-10-2020 00:31:09 Normal File--> 20,806,656 /var/www/scratch/chaste.bak/db/rep-cache.db [Sent]
25,640,960 21-10-2020 00:14:39 Normal File--> 25,640,960 /var/www/scratch/buildbot/master/state.sqlite [Sent]
26,422,578 21-10-2020 00:33:27 Normal File--> 26,422,578 /var/log/apache2/access.log Changed
27,262,976 21-10-2020 00:33:21 Normal File--> 27,262,976 /var/lib/mysql/ibdata1 [Sent]
46,948,528 21-10-2020 00:37:09 Normal File--> 46,948,528 /var/mail/svn [Sent]
699,631,490 21-10-2020 00:33:15 Normal File--> 699,631,490 /var/lib/mlocate/mlocate.db [Sent]
1,625,510,849 21-10-2020 00:37:01 Normal File--> 1,625,510,849 /var/mail/root [Sent]
2,570,941,138 21-10-2020 00:25:11 Normal File--> 2,570,941,138 /var/www/scratch/buildbot/master/twistd.log Changed
10,642,110,311 21-10-2020 00:14:33 Normal File--> 10,642,110,311 /var/www/scratch/buildbot/master/http.log [Sent]
Looks like backups weren't properly configured. A particular problem is
Comment by jmpf on 2020-10-22 at 11:57:59
sudo rm /var/mail/root
Comment by jmpf on 2020-10-22 at 12:12:30
Reconfigure backup
$ diff -u /opt/tivoli/tsm/client/ba/bin/dsm.sys.0 /opt/tivoli/tsm/client/ba/bin/dsm.sys
--- /opt/tivoli/tsm/client/ba/bin/dsm.sys.0 2020-10-22 12:57:13.272333478 +0100
+++ /opt/tivoli/tsm/client/ba/bin/dsm.sys 2020-10-22 13:06:41.739554442 +0100
@@ -132,3 +132,9 @@
*Exclude.fs /tmp
*Exclude.fs /var/tmp
+* Don't backup log files (largest is currently ~40Mb)
+Exclude.dir /var/log
+
+* Don't backup buildbot's logs (10Gb and 2Gb and stored on spinning rust drive).
+Exclude /var/www/scratch/buildbot/master/http.log
+Exclude /var/www/scratch/buildbot/master/twistd.log
$ sudo /opt/tivoli/tsm/client/ba/bin/HFSscheduler stop
$ sudo /opt/tivoli/tsm/client/ba/bin/HFSscheduler start
Comment by jmpf on 2020-10-22 at 12:13:22
Stop stdout of the cron launched backup going to email (it's logged already).
diff -u crontab.old crontab.new
--- crontab.old 2020-10-22 13:11:07.433060187 +0100
+++ crontab.new 2020-10-22 13:11:51.645310653 +0100
@@ -20,5 +20,5 @@
# For more information see the manual pages of crontab(5) and cron(8)
#
# m h dom mon dow command
-15 0 * * 1,2,4,5,6 dsmc incremental # Back up everything after midnight
-* 8 * * * /sbin/swapoff -a && /sbin/swapon -a # Recover any swap at 8am
+15 0 * * 1,2,4,5,6 dsmc incremental > /dev/null # Back up everything after midnight
+* 8 * * * /sbin/swapoff -a && /sbin/swapon -a # Recover any swap at 8am
Comment by jmpf on 2020-11-05 at 16:20:47
This morning Thu 5 November the Chaste Trac was unavailable in the late morning. Machine was still completing the Wednesday dsm backup at lunchtime and swap space had not been recovered.
Trac killed. Apache restarted. Backup left to complete. Machine settled down.
Comment by jmpf on 2020-11-11 at 17:50:20
Last night (Tues 10 Nov) the automatic scheduler failed to trigger and I had to restart the HFSscheduler service.
Comment by jmpf on 2020-11-25 at 10:40:01
Last night (Tues 25 Nov) at 22:10 the website was unavailable. Scheduled backup happened normally but the machine was still swapping this morning.
I'm suspicious of
24-11-2020 22:38:47 Normal File--> 2,493,455,360 /var/www/chaste_test_data/.stats-nightly.db [Sent]
which may have filled the swap sometime after 10pm.
Excluding:
chaste@chaste:~$ diff -u /opt/tivoli/tsm/client/ba/bin/dsm.sys.1 /opt/tivoli/tsm/client/ba/bin/dsm.sys
--- /opt/tivoli/tsm/client/ba/bin/dsm.sys.1 2020-11-25 10:36:25.410851734 +0000
+++ /opt/tivoli/tsm/client/ba/bin/dsm.sys 2020-11-25 10:38:57.867730857 +0000
@@ -138,3 +138,5 @@
* Don't backup buildbot's logs (10Gb and 2Gb and stored on spinning rust drive).
Exclude /var/www/scratch/buildbot/master/http.log
Exclude /var/www/scratch/buildbot/master/twistd.log
+* Don't backup nightly test database (2.5Gb stored on spinning rust drive).
+Exclude /var/www/chaste_test_data/.stats-nightly.db
Please see the guides, and discussions for answers to common problems.
Describe the bug
When using cmake for chaste on a new Ubuntu 22.04 machine after following wiki install guidelines you get the following error:
// BEGIN//
The imported target "vtkParseOGLExt" references the file
"/usr/bin/vtkParseOGLExt-7.1"
but this file does not exist. Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
"/usr/lib/cmake/vtk-7.1/VTKTargets.cmake"
but not all the files it references.
-- The imported target "vtkRenderingPythonTkWidgets" references the file
"/usr/lib/x86_64-linux-gnu/libvtkRenderingPythonTkWidgets.so"
but this file does not exist. Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
"/usr/lib/cmake/vtk-7.1/VTKTargets.cmake"
but not all the files it references.
-- The imported target "pvtk" references the file
"/usr/bin/pvtk"
but this file does not exist. Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
"/usr/lib/cmake/vtk-7.1/VTKTargets.cmake"
but not all the files it references.
-- VTK version: 7.1
-- No HDF5 found in /usr/lib/petscdir/3.15/: looking for alternative HDF5 instead
-- Could NOT find MPI_C (missing: MPI_C_WORKS)
CMake Error at /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find MPI (missing: MPI_C_FOUND) (found version "3.1")
Call Stack (most recent call first):
/usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
/usr/share/cmake-3.22/Modules/FindMPI.cmake:1830 (find_package_handle_standard_args)
CMakeLists.txt:428 (find_package)
// END //
To Reproduce
The only way I am currently aware of reproducing this issue is attempting to install and then cmake chaste on a freshly built Ubuntu 22.04 system.
START FROM FRESH SETUP
sudo nano /etc/apt/sources.list.d/chaste.list
** deb [signed-by=/usr/share/keyrings/chaste.asc] http://www.cs.ox.ac.uk/chaste/ubuntu jammy/ **
sudo wget -O /usr/share/keyrings/chaste.asc https://www.cs.ox.ac.uk/chaste/ubuntu/Chaste%20Team.asc
sudo apt-get update
sudo apt-get install chaste-dependencies
git clone --recursive -b release https://chaste.cs.ox.ac.uk/git/chaste.git Chaste
sudo apt-get update
sudo apt-get install --install-recommends chaste-dependencies
sudo apt-get install `dpkg -s chaste-dependencies | egrep "^Suggests" | cut -d "," -f 1-111 --output-delimiter " " | cut -d ":" -f 2`
mkdir Chaste_build
cd Chaste_build
cmake &PATH TO CHASTE
**THE ABOVE ERROR WILL APPEAR**
Expected behavior
Cmake should work normally and then allow you to make with Chaste
System
Please provide relevant details of your system, such as:
**Additional context**
Thus far this has only been seen on 2 clean machines built with 22.04 and one machine updated from 20.04 to 22.04
I am running a cell simulation with a node-based off-vertex model.
I set some nodes and run my simulation for 10 hours with a cell cycle uniform 1 hour.
After some time I get this failed test error: The point provided is outside all of the boxes
From this block of code:
template<unsigned DIM>
unsigned DistributedBoxCollection<DIM>::CalculateContainingBox(c_vector<double, DIM>& rLocation)
{
// The node must lie inside the boundary of the box collection
for (unsigned i=0; i<DIM; i++)
{
if ((rLocation[i] < mDomainSize(2*i)) || !(rLocation[i] < mDomainSize(2*i+1)))
{
EXCEPTION("The point provided is outside all of the boxes");
}
}
When I run the same test for shorter periods of time, the error goes away.
I think this means that the box does not increase as the population increases.
Is this the case?
This issue continues the discussion for legacy trac ticket 3060:
mirams created the following ticket on 2021-04-06 at 10:13:32, it is owned by mirams
Released recently: https://www.mcs.anl.gov/research/projects/petsc/documentation/changes/315.html
There could be some changes that need addressing.
Todo:
Comment by jmpf on 2022-06-17 at 11:44:58
Ubuntu 22.04 LTS uses this version of PETSc. There are some failures on 22.04, notably KSP exceptions in the tests in TestCardiacElectroMechanicsTutorial
. It's likely that they are caused by the change of PETSc, but should be investigated further.
Comment by jmpf on 2022-07-06 at 14:41:49
I think I've got a working version of Chaste with PETSc 3.15 now:
6: <Libraries>
6: <CompiledIn>
6: <PETSc>3.15.5</PETSc>
6: <Boost>1.71.0</Boost>
6: <HDF5>1.12.0</HDF5>
6: <Parmetis>4.0.3</Parmetis>
6: </CompiledIn>
The fact that it's pulled in HDF5 at 1.12 is a headache because there's interface changes there.
Unfortunately I haven't yet managed to replicate the error in TestCardiacElectroMechanicsTutorial
. That is, it passes this test suite. Further investigation needed.
Comment by mirams on 2022-07-06 at 15:08:21
([trac ticket 3063] is the ticket for HDF5 1.12, no work on it yet!)
Additional BuildBot tasks that still require migration:
doxygen
, then upload to new website)infrastructure
)Hi,
I am not sure if this is the place to ask, but I am running chaste from the docker image and using a project, In this project I have a psvm file to load the specific geometries.
paraview_error.txt
When I did this in an older version of para
view, I had no problems (version 5.6 had some warnings, but still worked), Now these warning have become errors.
Please see the attached file.
Is there a straightforward action that I need to take to fix this problem or is it more involved?
This is part of the work for issue #38
ci
branch to run tests with new images@mirams lest us know what you think.
yesterday in the meeting I asked for --recursive to be added in the automated testing script, so cellml files could be included from the cellml repo. However @fcooper8472 didn't like this idea bcause even if you provide instructions many people just copy-paste from gitub and it would break stuff. As an alternative he suggested using cmake_fecth.
I have just been trying this out and it works by downloading the cellml files at build time into the build folder.
The implcations of this as far as I can see:
There are several test failures with the Intel LLVM compiler:
https://github.com/Chaste/Chaste/actions/runs/4598286925/jobs/8122121029
Some of these relate to floating point values differing from expected values, due to Intel turning on fast-math optimisations by default. An example test suite that fails is TestHeartGeometryInformation
.
I have confirmed that the test fails with our default set of compiler flags, but passes when the flag -fno-fast-math
is added to the compile line.
It looks as though these failures are due to using TS_ASSERT_EQUALS
to test equality of floating point numbers. @jmpf is there any reason not to change these all to TS_ASSERT_DELTA
?
I am working with a cell-based off-lattice focusing on capsules project.
I want to perform some statistical modelling on the simulation data by running several thousand realisations.
Each time I run a simulation I get an associated output of several thousand files inside a results_from_time_XX
folder.
Most of these files are related to VTK and corresponding visualisation in ParaView.
I have a couple of classes that will write specific data in a .dat
file. These are all I need.
Broadly speaking is there any way to solve my simulation and not write anything to file other than my specific writer?
I know I have not provided anything specific, I can, but if there is like a general way to do this, that would be great.
This issue continues the discussion for legacy trac ticket 3013:
jmpf created the following ticket on 2022-07-27 at 09:35:17, it is owned by jmpf
There are two issues with coverage on buildbot@scoop
An upgrade from 16.04 to 20.04 caused the coverage tests to report some false negatives. These are mostly default: in switch statements: https://chaste.cs.ox.ac.uk/buildbot/Nightly%20Coverage/coverage1734/global/src/FileFinder.cpp.gcov.html
An recent upgrade to the PETSc version has caused the buildbot to stop being able to build (trac ticket 3075).
Comment by jmpf on 2022-07-27 at 09:45:26
16.04 had lcov 1.12-2
18.04 has lcov 1.13-3
20.04 has lcov 1.14-2
22.04 has lcov 1.15-1
Comment by jmpf on 2022-07-27 at 10:07:48
During the upgrade and reconfiguration from PETSc 3.6.2 to PETSc 3.12.5 I made a build that is ready to use with lcov: https://chaste.cs.ox.ac.uk/trac/ticket/3075#comment:7 I guess that the old stale CMake files are interfering. Deleted configuration and retesting.
Comment by jmpf on 2022-07-27 at 12:54:41
Replying to jmpf@…:
Deleted configuration and retesting.
That worked for nightly coverage and for nightly memory testing too.
Comment by jmpf on 2022-07-28 at 14:31:04
Way to build coverage on Scoop
mkdir Debug_develop
export PETSC_ARCH=linux-gnu
export PETSC_DIR=/home/bob/petsc-3.12.5
export LD_LIBRARY_PATH=/home/bob/petsc-3.12.5/linux-gnu/lib
cmake -DCMAKE_BUILD_TYPE=Debug -DChaste_UPDATE_PROVENANCE=OFF -DChaste_COVERAGE_CPUS=11 ..
make -j12 Continuous Parallel
make -j6 coverage
# To repeat parts of post-processing from "make coverage"
usr/bin/lcov --config-file /home/jmpf/eclipse/workspace/Chaste/cmake/Config/lcovrc --directory . --capture --output-file coverage.info
/usr/bin/lcov --config-file /home/jmpf/eclipse/workspace/Chaste/cmake/Config/lcovrc --remove coverage.info "/home/bob/petsc*" "/usr/*" "*/fortests/*" "*/test/*" "*/3rdparty/*" "*/global/src/random/*" "Debug/*" "*/Debug_*/*" "cxxtest/*" --output-file coverage.info.cleaned set "(" _page_title "\"Chaste Coverage Results for commit \"" ")"
/usr/bin/genhtml --title "" --config-file /home/jmpf/eclipse/workspace/Chaste/cmake/Config/lcovrc --no-function-coverage -o coverage coverage.info.cleaned
#DON'T DO: /usr/bin/cmake -E remove coverage.info coverage.info.cleaned
/usr/bin/python3 /home/jmpf/eclipse/workspace/Chaste/cmake/process_coverage_output.py coverage
Comment by jmpf on 2022-07-28 at 14:34:22
The first issue with failing coverage from files which have been auto-generated. See top 3 lines of https://chaste.cs.ox.ac.uk/buildbot/Nightly%20Coverage/coverage1740/
This is caused by an incorrect wildcard/glob pattern and should be fixed by changing Debug_/ to /Debug_/* on line 844 of CMakeLists.txt.
Comment by jmpf on 2022-10-26 at 09:15:28
Note that existing work on this ticket is available:
git checkout ticket_3103
Comment by mirams on 2022-10-26 at 10:14:08
For those not so familiar with LCOV and how we have it set up see (track ticket 2858) for previous work and how to mark files, lines or blocks as purposely excluded etc.
Testing for @AlexFletcher
sdfs
Some test failures appear to result when using the intel compiler and the SmallPow method:
@jmpf suggested potentially re-writing this to not use recursion.
I looked into several different alternatives, and carefully audited the use of this method in the codebase.
The only time this method is appropriately called in Chaste, it is with an exponent of 4 or less.
After carefully profiling, there is a speedup of around 20% using our hand-coded method vs using std::pow
. This is due to the standard library having no specialization for positive integer powers.
Given that it is called a lot, I propose extending the switch statement to explicitly include a case for an exponent of 4, and then default to using std::pow
for larger exponents.
This method was also being used in various mesh generators to create a variable that was either -1 or +1 depending on the exponent. All of these uses should be changed to not use exponentiation for this purpose.
As a side note, the equivalent SmallPow specialized for unsigned integers is rarely used, and also never above an exponent of 4, do I don't think it's worth modifying that at all.
I am trying to run the demos written in the joss paper using the pre-built docker image and the command
docker run -it --init --rm -v chaste_data:/home/chaste chaste/chaste-docker:2019.1
Inside this container, the environment variable CHASTE_SRC
is called CHASTE_SRC_DIR
instead, and the output directory is called testoutput
instead of test_summary
as you write in the paper.
It would be good if you could tag one docker image that had the exact same folder structure and environment variables as you describe in the paper.
By the way, everything seems to run fine using the correct folders.
Hi there,
I notice in files such as mesh/src/HoneycombMeshGenerator.cpp
that the nodes, elements, and edges are all manually computed and written to temporary .node
, .elem
, and .edge
files and used to generate the mpMesh
instance.
Is there a reason that this can't be replaced with MutableMesh::AddNode
method and then a call to MutableMesh::ReMesh
? The rough code outline of what I am talking about is shown below:
// mesh/src/HoneycombMeshGenerator.cpp lines 95-130
unsigned node = 0;
// add middle layer of cells
for (unsigned i=0; i<num_nodes_along_length; i++)
{
for (unsigned j=0; j<num_nodes_along_width; j++)
{
/**
* handle ghost node indices, boundary, compute x, y etc etc
**/
mpMesh->AddNode(new Node<2>(node++, boundary, x, y));
}
}
mpMesh->ReMesh();
The reason I am asking is because I want to create my own mesh generator class, and it would be far easier to just compute the node positions and let the MutableMesh
instance take care of computing the connectivity, elements, faces etc, especially if I want to work in 3D.
Test bug report
This issue continues the discussion for legacy trac ticket 2097:
jonc125 created the following ticket on 2012-04-26 at 11:15:53, it is owned by jonc125
This (or something like it) was requested at the workshop. One suggestion was to install a stackoverflow style instance for user questions.
This is a child of (trac ticket 1989), which opened up parts of the Chaste Trac system to the public. See in particular comment:8🎫1989, which suggests using OSQA, with LDAP auth in order to share credentials with Trac.
See also http://scicomp.stackexchange.com/ and http://www.biostars.org/.
Comment by mirams on 2015-03-02 at 12:03:32
The Biostars one is specifically for science software, and still in active development https://github.com/ialbert/biostar-central Looks like a good bet to me.
Comment by fcooper8472 on 2017-06-12 at 16:14:37
I have recently investigating this as part of (trac ticket 2904).
Biostars looks reasonable, but I have the following thoughts:
For these reasons, I think we should limit the installation of any new tools on the Chaste server, and the integration of anything new with trac.
My suggestion, instead, would be to start making greater use of GitHub. Now that we have the releasable code hosted publicly, it would make sense in my mind to migrate (over time) a number of things (topic for another ticket!).
Specifically regarding the mailing list, I think the GitHub issues form a very natural way for us to do what we want:
Issues are similar to trac tickets. They can be assigned to people and to projects, and have labels and milestones.
Default labels include bug and question. Multiple labels can be applied to an issue. Were we to encourage users to submit issues instead of emailing the list, any of us could assign, for instance, question and component: cell_based labels, and assign the relevant developer per the question subject.
Importantly, no sign-up is necessary to see issues, and a GitHub account is all that is necessary to create a new issue, which would prevent us needing to do any user administration.
Issues are open until they are closed. This would hopefully prevent any questions being forgotten about.
We can provide a direct link to the questions 'section', as opposed to all issues: https://github.com/Chaste/Chaste/labels/question
My feeling is that this is an improvement on the mailing list, and does not require setting up anything new.
Are there:
Comment by martinjrobins on 2017-06-12 at 17:13:54
I think GitHub issues would work well instead of a forum. Obviously a dedicated forum webserver would be most suitable for this, but its a lot of work to maintain a server for anything, and I think the trade-off is worth it.
Con:
You can't refer to a new commit on a GitHub issue until buildbot pushes it :(
Pro:
If we want the GitHub repo to be the public face of Chaste, then it is nice for users to see a lot of recent opened/closed issues, shows that a project is active and the developers are responsive. So good advertising!
Comment by jmsgrogan on 2017-06-13 at 07:54:09
Definite +1 for Github issues, it is the first place I go to if something isn't working in other codes and will show up better in Google searches.
Comment by mirams on 2017-06-13 at 09:27:50
Not sure. A Q&A site with:
are all very very useful, and those things are the main point of moving away from a mailing list rather than simply not losing issues. There must be loads of Q&A open source things by now?
Comment by jonc125 on 2017-06-13 at 09:36:40
You can edit comments in GH issues. Not sure about voting, and it's possible to jump to the end of a thread!
The main downside of using an open source Q&A is that we have to host it and maintain the server, applying updates, etc. And we have no-one to do this.
Comment by mirams on 2017-06-13 at 09:43:45
Is there some way to edit someone else's comments on a github issue? (Quite often on stackoverflow the question as well as answers get edited to make more sense!).
Comment by martinjrobins on 2017-06-13 at 09:46:53
I just tried it, and I can edit someone else's (another collaborator on the same project) comments on an issue.
Comment by MichaelClerx on 2017-06-14 at 09:58:06
You're all talking about issues, but the ticket was about user questions :-)
Github is for issues that need resolving. As soon as an issue/bug/feature-request is resolved it disappears. It's main users are developers.
The ticket here is for a user Q&A, to help people use the bug-free software. So main users are end-users, and answered questions will be more popular/relevant than new ones.
Comment by martinjrobins on 2017-06-14 at 10:09:36
but Github issues end up being a defacto user forum for many open source projects. You can label issues depending on what they are (e.g. bug, help wanted, question, or any custom label), and you can still see closed issues (or just don't close FAQs)
Comment by MichaelClerx on 2017-06-14 at 10:22:44
You can do it, just not a good idea
The first option in the tab menu is code, 2nd is issues - not questions!, 3d is pull requests. There's a button for forking right at the top. To see previously answered questions you need to remove the "is:open" filter manually, OR the entire community has to remember not to close them. Totally geared towards developers!
There's a case to be made for Chaste users typically being developers, sort of, but that should become less and less the case once the core stabilises and people start using it via PyChaste or super-easy-c14 right?
Comment by martinjrobins on 2017-06-14 at 10:31:00
I think a dedicated user forum is better than github issues, cause that is what it is designed to do, but not worth the extra work in maintaining a server (or paying for a hosted solution). But if you're volunteering to do this, I think discourse is a good solution (https://www.discourse.org/) ... :)
Comment by fcooper8472 on 2017-06-14 at 11:24:53
I agree that github issues aren't perfect. But, I really think it's worth stressing that we don't have anyone in a position to be responsible in the long run for another instance running on chaste.cs. We are already, I think, likely to run into issues with trac etc, 18 months from now when we need to upgrade the OS on chaste.cs.
The benefits of github are that:
The 'middle ground' option would be to create an 'issues only' repo on Chaste: maybe named User Questions
or FAQ Blog
, or similar, that we advertise as the place to ask and answer the sorts of questions we currently get on the mailing list.
We could then decide to never close a question, if that makes it easier for people to find the answers, and it would separate 'dev' issues from user questions quite nicely.
Either way, unless anything changes drastic changes, I think the options are realistically between continuing with the mailing list, and using github.
Comment by mirams on 2017-06-14 at 15:56:58
Michael will have a play with discourse (which is free if you host it yourself) on chaste.cs.ox.ac.uk at some point, and can use third party google/twitter/facebook logins so we wouldn't have to manage that. Maintaining owncloud on trix has been pretty easy, even for me who doesn't understand web servers, so I think it is worth the minimal effort for a much better system.
Comment by MichaelClerx on 2017-09-15 at 19:42:41
Question2Answer example is up and running on https://chaste.cs.ox.ac.uk/questions
Let me know if anything else on https://chaste.cs.ox.ac.uk/ is broken!
Comment by mirams on 2017-09-15 at 22:17:20
When you press the button to 'flag' a post you get asked to confirm your email and it sends a link.
Only problem I've found is that you can't confirm, because this email has a http://
instead of https://
link. If I manually changed it, then it works.
Can we alter apache settings to re-route http to https for /question?
Comment by MichaelClerx on 2017-09-15 at 22:59:23
I'm not sure! I've tried making apache reroute http:// to https:// but it didn't seem to work.
Is it something to do with the greater oxford/cs infrastructure? Our webmail also hangs indefinitely if you use http instead of https...
Comment by mirams on 2017-09-15 at 23:50:59
Replying to GaryM:
Only problem I've found is that you can't confirm, because this email has a http:// instead of https:// link. If I manually changed it, then it works.
I think I've fixed this problem in the admin settings by telling Q&A that it lives at the https:// address, so now it should be emailing links with that in.
Trac seems to be a bit slow, someone who knows things might want to check the new config!
Comment by MichaelClerx on 2017-09-16 at 00:10:07
Trac is very very slow from here! Not sure why though, haven't touched it...
Comment by MichaelClerx on 2017-09-16 at 00:11:33
Hold on, with the Oxford VPN turned off trac is really fast again!
Comment by fcooper8472 on 2017-09-17 at 20:15:33
Am I right in thinking that you need to register as a new user? Is there any way to integrate logins with trac?
Comment by MichaelClerx on 2017-09-18 at 07:53:24
It can be done by modifying a bunch of scripts! http://docs.question2answer.org/install/single-sign-on/
Should be easy provided someone knows how tracs user system works!
Comment by jonc125 on 2017-09-18 at 08:01:09
Trac just authenticates against an apache htpasswd file.
Comment by MichaelClerx on 2017-09-18 at 08:14:39
Really? So when I create an account for trac it stores my email address somewhere and then modifies the .htaccess file? When I log in I don't see the old-school browser popup login you usually get with an .htaccess authentication, how does that work?
Comment by jonc125 on 2017-09-18 at 08:19:28
.htaccess is different from htpasswd - the former is an apache config file, the latter is just a user/password store. Trac doesn't use HTTP Basic Auth (which is what pops up the box - although there are a few pages on the wider Chaste webserver that do), it just shares the user/password file with Apache. Email addresses etc are stored within Trac's database. There's some code in the old test infrastructure that reads email addresses from there IIRC, so it can tell people when they broke the build.
Comment by MichaelClerx on 2017-09-18 at 09:01:00
Ah, thanks! I can't find any trac integration plugins, so it looks like we'd have to do it ourselves.
Would require:
Comment by MichaelClerx on 2017-09-18 at 09:21:46
So not sure how that would work out with maintenance...
Comment by MichaelClerx on 2017-09-18 at 12:17:57
There's a (third-party) OpenAuth plugin, but the docs look like it's a bit of work to set up!
https://github.com/alixandru/q2a-open-login
Personally would just have users create a new account at this point...
Comment by mirams on 2017-09-18 at 12:56:40
Hmmmm, doesn't look too bad? Might be worth the effort to have something that will require one less username to worry about...
Comment by MichaelClerx on 2017-09-18 at 13:38:01
As a representative of the user community, jmpf would like the user info to come from trac.
This would mean:
Comment by jmpf on 2017-09-18 at 13:46:36
Replying to MichaelClerx:
As a representative of the user community, jmpf would...
Thanks. That's prompted me to add to the ticket.
Absolutely. My view is that adding the hurdle of an extra account sign up and log-in will cut the number of potential contributors (by as much as 75%). Since most reliable people to answer questions are all in the current trac population and the same website is using svn/trac authentication for svn, trac, git, buildbot, doxygen? then it's clear that svn/trac authentication ought to be the natural solution.
Comment by mirams on 2017-09-18 at 13:50:21
Hmmmmm, one problem is that not all trac users even have email addresses in the system... and a Q&A system isn't good if you have to go back and manually check for replies.
Comment by MichaelClerx on 2017-09-18 at 17:00:10
As far as I can see there are 278 people with a trac password and 232 with an email address (P.S. I've figured out how to do that ;-)
Comment by MichaelClerx on 2017-09-18 at 17:52:31
With the current architecture I think it's impossible to require trac users to have an email address (because it uses http authentication, which doesn't know/care about email).
Comment by MichaelClerx on 2017-09-18 at 17:57:10
Sorry for spamming, but this just occurred to me:
If you don't have a trac account and we go with the openauth implementation. Then we're potentially asking users to sign up for github/google whatever, instead of our own user registration, which you'll need to sign up separately. That seems wrong to me.
Comment by mirams on 2017-09-19 at 08:19:44
I think we might be worrying too much about this. If we do ever move Chaste to github or similar, then it will help to have a non-trac reliant system here. It takes about 10 seconds to sign up, and you can make that login identical to your trac one if you like.
Replying to MichaelClerx:
If you don't have a trac account and we go with the openauth implementation. Then we're potentially asking users to sign up for github/google whatever, instead of our own user registration, which you'll need to sign up separately. That seems wrong to me.
As far as I can work out, the oauth plugins work alongside the existing Q&A login (I played with enabling the inbuilt facebook one, and it added a new button for login with facebook), so we would still allow it to work as it does now, but just give more login options, including Stackexchange incidentally. I would see if that oauth plugin can be made to work in less than an hour, regardless of whether we try to sync the in-built login with trac.
Comment by MichaelClerx on 2017-10-12 at 09:28:20
Have tried to set up login via google, but that doesn't seem to work (for an unspecified reason, so bit stuck with debugging, have asked on their own q&a). The github login they advertise is nowhere to be seen in the admin pages so that's not looking great either.
Have had a look at integrating with trac and think this will be tricky (it doesn't want to simply read tracs user/pw files, it wants to have trac handle the whole login, and then share this session somehow. Would require more knowledge of how trac works than I have).
So how about we just keep it as a separate login? It only takes a few seconds...
Comment by mirams on 2017-10-12 at 09:54:30
I am fine with a separate login, you have to sign up for the mailing list separately at the moment anyway.
Comment by MichaelClerx on 2017-10-12 at 10:00:42
Good! So shall we start migrating some of the mailing list questions then?
Comment by mirams on 2017-10-12 at 10:34:16
If others agree!
Comment by fcooper8472 on 2017-10-12 at 10:47:13
I'm definitely up for giving this a go, but do worry somewhat about the takeup.
If we could get the Google (and other) logins working alongside, I think that would be great to have, but let's at least test the waters...
Comment by mirams on 2017-10-12 at 11:01:18
Presumably we could first of all tell the mailing list people about it, then after a couple of weeks set up the mailing list to auto-reply to posters telling them to go to the Q&A site instead?
Comment by fcooper8472 on 2017-10-12 at 13:05:30
Potentially very important: is there any facility (or can there be facility) for Markdown support (or else something similar), so that we can easily write code blocks?
If we can't format code well, it might cause issues!
Comment by MichaelClerx on 2017-10-16 at 09:13:28
Code formatting works now, and has support for C++, Make, CMake, Bash and ini files (it should be able to auto-detect these). The formatting happens via javascript, so doesn't always happen instantly I'm afraid.
Markdown parsing is done by code from stackexchange, so follows the same rules (use indenting to start a code block).
Comment by mirams on 2022-10-24 at 15:14:29
Github now has special discussion pages that seem perfect for this, so that's now a very sensible option, and means they will have good ways of dealing with user authentication and spam etc. So we could switch these on.
Comment by MichaelClerx on 2022-10-24 at 15:28:59
Sounds good to me!
Test
One thing that is very useful when working with simulation software is to have some way to compare the results with other similar simulation frameworks. Benchmarks are very useful to both compare solutions of specific problems as well as a nice toy example to work with to get a good understanding of how to use the software.
I would encourage you to add a section in your documentation where you provide solutions of different benchmarks and add the corresponding source code used to generate those results. In particular I know about a cardiac mechanics as well as a cardiac electrohpyisology benchmark (but you could probably find more)
Note that this is not a requirement for publication in JOSS.
The new CI workflow for memory testing runs on a self-hosted runner (currently the new Chaste server in Oxford). This is necessary because the full test suite takes slightly longer than the allowed 6 hours on a GitHub hosted runner.
The server is running Ubuntu 22.04 LTS, which supplies Valgrind-3.18.1.
An example set out outputs from this version is available here:
https://chaste.github.io/memory-testing/2023-03-16_14-00-34/index.html
Every test is marked as leaking, and this may be related to the following warning:
==923004== WARNING: pwritev(vector[...]) is an obsolete suppression line not supported in valgrind 3.15 or later.
==923004== You should replace [...] by a specific index such as [0] or [1] or [2] or similar
It may be the case that our memory testing suppressions are out of date and need re-creating.
Previous memory testing, available for the time being on the BuildBot waterfall, does not have the same issue, and the overall memory test suite is passing:
https://chaste.cs.ox.ac.uk/buildbot/Nightly%20MemTest/memtest1804/
Please see the guides, and discussions for answers to common problems.
Describe the bug
When merging develop into an older branch (auatay_ticket_2987_ode_edges) once correcting all conflicts and issues the only Continuous test to fail is TestArchiveFormat to fail. Determined that this is specifically to the following files:
cell_population_sim_at_time_150.arch
cell_population_sim_at_time_150.arch.0
mesh_150.edge
mesh_150.ele
mesh_150.ncl
mesh_150.node
This issue can be corrected by re-running TestGenerateSteadyStateCrypt and then copying the corresponding output files back into the correct crypt location.
To Reproduce
Steps to reproduce the problem.
** Assuming here user is already on the development branch and has correctly built Chaste**
cd chaste
git checkout
git checkout auatay_ticket_2987_ode_edges
cd build
make -j4 Continuous
ctest -j4 -L Continuous
** All tests here will pass except for TestArchiveFormat **
** Then Wed do the following to correct it **
make TestGenerateSteadyStateCrypt
ctest -R TestGenerateSteadyStateCrypt
cp /tmp/$USER/testoutput/SteadyStateCrypt/archive/?*_150.* ../crypt/test/data/SteadyStateCrypt/archive/
make -j4 Continuous
ctest -j4 -L Continuous
** TestArchiveFromat will now pass**
**Expected behavior**
TestArchiveFormat should pass with no errors but instead is unable to even run properly.
**System**
Please provide relevant details of your system, such as:
Ubuntu 18.04.6 LTS
cmake version 3.24.1
I'm not familiar to using cmake, and while following the user guide for installation,
I met this configuring error down below., Is there any way to solve this issue,?
CMake Error at cmake/Modules/ChasteMacros.cmake:90 (add_custom_command):
add_custom_command Wrong syntax. A TARGET or OUTPUT must be specified.
Call Stack (most recent call first):
cmake/Modules/ChasteMacros.cmake:301 (chaste_do_cellml)
cmake/Modules/ChasteMacros.cmake:401 (Chaste_DO_COMMON)
heart/CMakeLists.txt:56 (chaste_do_component)
OS: Ubuntu 18.04.5 LTS
Describe the bug
TestGenerateSteadyStateCrypt fails on ubunto jammy but passes on bionic.
'''
test 326
Start 326: TestGenerateSteadyStateCrypt
326: Test command: /home/uczmh2/develop/chaste_build/crypt/test/TestGenerateSteadyStateCrypt
326: Test timeout computed to be: 10000000
326: Running 1 test
326:
326: ***** TestGenerateSteadyStateCrypt.hpp *****
326:
326:
326: Entering TestGenerateSteadyStateCryptArchives
326:
326: /home/uczmh2/develop/Chaste/crypt/test/simulation/TestGenerateSteadyStateCrypt.hpp:175: Error: Expected (expected_cell_count_lb < p_simulator->rGetCellPopulation().GetNumRealCells()), found (425 >= 422)
326: Failed
326:
326: Failed 1 of 1 test
326: Success rate: 0%
1/1 Test #326: TestGenerateSteadyStateCrypt .....***Failed 1248.60 sec
This issue continues the discussion for legacy trac ticket 3104:
kwabenantim created the following ticket on 2022-09-02 at 11:33:49, it is owned by kwabenantim*
For those without C++ expertise, implementation of higher-level programming language bindings would offer a step change in Chaste’s usability. Extending on preliminary work in [legacy ticket 2686] on PyChaste, we will use PyBind11 to generate Python wrappers for cell-based Chaste.
For AP portal it would be quite useful if some information could be output to progress_status.txt about the fact that the CellML file is being converted. This does take a bit of time, so it would be nice to be bale to give feedback to portal users, otherwise they may wrongly assume the simulation has failed to start.
In the folder eclipse settings we seem to have some rather old settings for the eclipse IDE. I'm coming across these as I'm trying to remove references to SCons (#73 ).
I'm just wondering if we need to keep these clipse settings, I don't think they actually work or have been used by anywabody in a while. What do people think?
Hello there, I am new to the community.
I was trying to execute the first run case following the tutorial web-page. The building step succeeded without troubles, however, the compilation of Continuous failed, showing up the following error message
Chaste/mesh/src/reader/VtkMeshReader.cpp:106:40: error: ‘virtual void vtkUnstructuredGrid::GetCellTypes(vtkCellTypes*)’ is deprecated: Please use GetDistinctCellTypesArray() instead. [-Werror=deprecated-declarations] mpVtkUnstructuredGrid->GetCellTypes(cell_types);
The VTK version I have installed is the following 9.1, Looking after your comments I salute you.
Edit: If prompted I can edit the file that the compiler complains about but I'm afraid more trouble can appear... What current versions are you using?
Please see the guides, and discussions for answers to common problems.
Describe the bug
I tried to run the docker chaste on an apple mac with an M1 chip. The current docker is setup to do this.
Can I get confirmation of this?
If so, when or how should we go about spinning that up?
To Reproduce
Steps to reproduce the problem.
git clone --recursive https://github.com/Chaste/Chaste.git chaste
cd chaste
mkdir build
cmake ..
CMake Error: The source directory does not appear to contain CMakeLists.txt.
Specify --help for usage, or press the help button on the CMake GUI.
Expected behavior
A clear and concise description of what you expected to happen.
System
Please provide relevant details of your system, such as:
Some of this information can be generated by running TestChasteBuildInfo
:
git clone --recursive https://github.com/Chaste/Chaste.git chaste
cd chaste
mkdir build
cd build
cmake ..
cmake --build . --target TestChasteBuildInfo
ctest -V -R TestChasteBuildInfo
Please paste the full output in a code block. It will be similar to the truncated example below.
6: ***** TestChasteBuildInfo.hpp *****
6: Entering TestShowInfo
6: <ChasteBuildInfo>
.
.
.
6: </ChasteBuildInfo>
6: Passed
6: OK!
1/1 Test #6: TestChasteBuildInfo .............. Passed 2.38 sec
Additional context
Include additional information about the problem here if relevant.
Screenshots
If applicable, add screenshots to help explain your problem.
This is a continuation of #2713
mirams created the following ticket on 2015-07-31 at 16:16:18, it is owned by mirams
I've been looking into CVODE's error handling a bit more as people like Kylie and Ross are having some problems. In the CVODE documentation they suggest that you raise a 'recoverable error' flag in the RHS as soon as you see any unphysical values, it will then go back and refine, hopefully earlier than it would otherwise, preventing terrible explosions.
I'm going to try hijacking the VerifyStateVariables()
method for this.
It would be good if we could auto-generate more of the entries in it, by putting the zero to one limits on all probabilities and a lower limit of zero on all concentrations.
We have a tag for concentrations, but need one for probabilities - i.e. all HH Gating variables, or Markov Model states. To do this we could add another metadata tag such as
:probability
a :Annotation ;
rdfs:label "Probability - a Hodgkin-Huxley gating variable or Markov model state variable" ;
rdfs:comment "This annotation will be used to set numerical limits on the values this variable can take to check solver accuracy." .
Does that make sense Jon, and could you make PyCML play ball with anything that has these annotations?
status: new
cc: trac user [email protected]
type: user story
priority: normal
component: pycml
milestone: Future
effort: 4
effortexpended: 0
initialeffort: 4
Comment by trac user [email protected] on 2016-01-11 at 14:04:24
Filing old email and came across this. Certainly technically possible. Depends on priority as to when it gets done :)
In particular, we already have annotations for setting upper/lower limits on variables that cause code to be generated in VerifyStateVariables
. So it would just be a matter of adding the reasoning that some category tags imply particular limits.
Apparently its not possible to link to another user project from within a separate user project. The problem appears when trying to build using cmake. However, this isn't a issue while using scons.
I am facing this problem for my user project "ApPredict_GP" (https://github.com/sanmitraghosh/ApPredict_GP) which uses some of "ApPredict" (https://github.com/Chaste/ApPredict) code.
Updated description to show remaining tasks:
This issue continues the discussion for legacy trac ticket 3081:
fcooper8472 created the following ticket on 2021-12-01 at 17:49:37, it is owned by fcooper8472
Joe and I have recently migrated our primary git repo to GitHub.
All branches are now available here: https://github.com/Chaste/Chaste
Items left to do:
Comment by AlexFletcher on 2022-04-28 at 08:49:46
Does this ticket include tasks associated with moving from trac tickets to e.g. github projects? If so, then an outstanding task is to investigate how to create a github project associated with the BBR grant, and implement this; otherwise, we should create a new ticket for this task.
Comment by fcooper8472 on 2022-05-20 at 11:04:09
We want to:
This issue continues the discussion for legacy trac ticket 2905:
fcooper8472 created the following ticket on 2017-05-18 at 13:53:53, it is owned by fcooper8472
Prior to Release 17.4, we need to update the wiki in light of several major changes:
The goal is that, by clicking through links from the front page it should be impossible to access defunct instructions without it being obvious they are defunct!
Old versions of pages that we will never want to change can be linked to from under SconsArchive (like old AttendancePlan are listed). But if there's even a chance the scons way of working will be modified (for c++11 etc.) we may still need to update them, and so we'll need live wiki pages: in this case they should be copied to new wiki pages under SconsArchive. N.B. you can rename wiki pages to move them under SconsArchive using button at the bottom of the pages.
apps
folders (moved scons instructions to SconsArchive/BuildingCardiacExecutable - which also applied to projects etc.)etc. etc.
Comment by fcooper8472 on 2017-05-19 at 15:06:10
GettingStarted is now up-to-date. Please make changes/edit as you see fit.
Comment by fcooper8472 on 2017-05-31 at 15:56:25
done
GettingStarted (update figure etc.)
done
[ChasteGuides] (remove info on cardiac executable?)
done
ChasteGuides/RunningFirstTests (ChasteGuides/CmakeFirstRun)
done
InstallGuides/InstallGuide (bottom bit).
done
UserTutorials (scons at the top)
done
ChasteGuides/VisualisationGuides/CombineConsecutiveSimulations
ChasteGuides/HostconfigSystem (new guide for when cmake doesn't pick them up?)
done
too.Something on building executables in apps
folders (moved scons instructions to SconsArchive/BuildingCardiacExecutable - which also applied to projects etc.)
done
.MakingARelease
InstallGuides/Arc#GettingChaste
Comment by mirams on 2017-06-01 at 10:40:31
I think the information on:
would be better on three dedicated wiki pages (updating/replacing/renaming ChasteGuides/HostconfigSystem; ChasteGuides/BuildingCardiacExecutable; ChasteGuides/RunningAcceptanceTests respectively) to make CmakeBuildGuide less of an overwhelming monster sized page.
The CmakeBuildGuide needs a bit of reading with a novice hat on, for a lot of our users this might be the first c++ project they have built from source using cmake. When we say things like "You can specify a Boost directory by using the BOOST_ROOT CMake variable" or "You can specify a Sundials folder by setting the SUNDIALS_ROOT environment variables" it would be much better to give things to type on the command line. Similarly we need to explain what "install the Chaste libraries", "Packaging your build" mean (I don't know what this last one means!).
Perhaps we can put a bit of the expert stuff on a ChasteGuides/CmakeAdvancedBuildGuide? things like make tutorials
are going to understandably cause confusion if listed in the users' CmakeBuildGuide.
Comment by fcooper8472 on 2017-06-01 at 13:26:43
ChasteGuides/BuildingExecutableApps now exists.
Comment by fcooper8472 on 2017-06-01 at 14:06:56
There is now a ChasteGuides/FindingChasteDependencies, and the relevant information has been moved over from the Cmake Build Guide.
Comment by fcooper8472 on 2017-06-01 at 14:35:30
I have changed the default repository on trac.
If you go to the browse source tab now, you should see the main git repo.
Comment by mirams on 2017-06-01 at 14:42:43
Replying to fcooper:
I have changed the default repository on trac.
If you go to the browse source tab now, you should see the main git repo.
This does mean that all links to svn changesets are broken though - any way to automatically mend the existing links (changerXXXX
to[rXXXX](changeset:XXXX/svn_repo)
sort of thing)?
Comment by fcooper8472 on 2017-06-01 at 14:58:46
Replying to GaryM:
Replying to fcooper:
I have changed the default repository on trac.
If you go to the browse source tab now, you should see the main git repo.
This does mean that all links to svn changesets are broken though - any way to automatically mend the existing links (changerXXXX
to[rXXXX](changeset:XXXX/svn_repo)
sort of thing)?
Agh, that's a massive pain...
It might be possible to add some functionality to TracWebUtils.py
or TracDbUtils.py
to crawl every page on the wiki and do some regex magic.
Sounds dangerous though! Not to mention I'm not sure how one would deal with tickets, which would be the main issue.
Any ideas?
Comment by mirams on 2017-06-01 at 15:04:13
I'm tempted to say it's not too hard to copy the revision number into the search box and get where you need to fairly fast, since most 'active' work will now be on git repo, and using that will be much easier (won't need the /git_repo
for that presumably any more?). But we should probably check with everyone else on slack #general or something.
Comment by fcooper8472 on 2017-06-05 at 10:53:41
Just to take stock, the following aren't crossed out yet:
Guides:
ChasteGuides/RunningAcceptanceTests (Input from Joe? - see [trac ticket 2908])
ChasteGuides/RunningBinariesFromCommandLine
InstallGuides/Arc#GettingChaste (Looks as though James is adding things right now)
MakingARelease (Could do with Gary and Joe in the same room for few mins)
Comment by fcooper8472 on 2017-06-05 at 11:21:51
ChasteGuides/RunningBinariesFromCommandLine is now up-to-date.
Comment by jmsgrogan on 2017-06-05 at 12:51:36
I've updated InstallGuides/Arc and moved the old Scons instructions into the archive. I've only had a chance to test this on Arcus-B, but have pointed to the old Scons guide for things that might be different on Arcus (A).
Describe the bug
The test suite TestPetscTools fails when run on more modern versions of PETSc. See
https://chaste.cs.ox.ac.uk/buildbot/builders/Nightly%20Continuous%20np3
To Reproduce
Configure with -DChaste_NUM_CPUS_TEST=3 and PETSc 3.12 and run the test suite.
Alternatively see https://github.com/Chaste/dependency-modules/actions/runs/3445084906/jobs/5748389962
In November 2022 Kwabena narrowed this down to PETSc 3.11:
PETSc Version | Parallel Test Result
3.7.7 | Pass
3.8.4 | Pass
3.9.4 | Pass
3.10.5 | Pass
3.11.3 | Fail
3.12.4 | Fail
3.13.6 | Fail
3.14.6 | Fail
3.15.5 | Fail
3.16.6 | Fail
Diagnosis
As of November I thought thought that this was a bug in PETSc from 3.11 onwards. The bug is manifest by a failure to obey the directions in the MatMPIAIJSetPreallocation
function on the processes which get ranks 1 or 2 in a parallel run. My action was to distil the problem into a minimal PETSc test (that passes 3.10 but fails 3.11) and then report it as a PETSc bug.
However, now that I have written a minimal test, I find that it's unable to reproduce the error. More investigation is needed to bring the failing test from TestPetscTools closer to the non-failing minimal test.
Describe the bug
Test TestAbstractContractionCellFactory fails in parallel -np3 on newchaste server which is running 22.04 LTS (Jammy). Also pertinent is that it compiles against PETSc 3.15 with g++ 11.3.
To Reproduce
See https://github.com/Chaste/Chaste/actions/runs/3938422099/jobs/6737088563
Expected behaviour
This test has an uncaught exception.
terminate called after throwing an instance of 'Exception'
System
This issue continues the discussion for legacy trac ticket 3088:
fcooper8472 created the following ticket on 2022-02-02 at 13:26:24, it is owned by fcooper8472
Changes can be seen here: https://www.kitware.com/vtk-9-0-0-available-for-download/
This currently prevents Chaste working (easily) on macOS as Homebrew gives v9.
Comment by jmpf on 2022-08-01 at 11:05:05
VTK9 was added to the rotation in February:
but it has yet to compile successfully: https://chaste.cs.ox.ac.uk/buildbot/builders/Portability%206_Sat?numbuilds=30
Comment by jmpf on 2022-08-04 at 13:33:48
Core components that need VTK are building fine (global, mesh,
etc.).
The cell_based
component fails when including VtkMeshReader.hpp
. This is probably because it doesn't have the correct include path, but I can't work out why that may be.
Comment by jmpf on 2022-10-24 at 15:17:59
Replying to jmpf@…:
Core components that need VTK are building fine (
global, mesh,
etc.).The
cell_based
component fails when includingVtkMeshReader.hpp
. This is probably because it doesn't have the correct include path, but I can't work out why that may be.
Note that this is a CMake configuration problem and is to do with the way CMake now detects libraries and include paths.
Dear developers.
I'm having some problems with the installation of chaste. My Ubuntu version is 20.04 LTS and I installed it using the Ubuntu package as described in "https://chaste.cs.ox.ac.uk/trac/wiki/InstallGuides/UbuntuPackage". I installed Chaste using the Ubuntu package as described in "" and did not encounter any errors at this step. Then I compiled as described in "https://chaste.cs.ox.ac.uk/trac/wiki/ChasteGuides/CmakeFirstRun" and in the configuration step I got the following message:
"-- Configuring done
-- Generating done
-- Build files have been written to: /path/to/chaste_build "
without any errors.
But when I perform the build step, I type "make -j4 Continuous" and I get the following error:
gwqsz@gwqsz-VirtualBox:~/chaste/chaste_build$ make -j4 Continuous
Scanning dependencies of target timekeeper
Scanning dependencies of target testglobal
Scanning dependencies of target testmesh
Scanning dependencies of target testode
[ 0%] Building CXX object global/CMakeFiles/timekeeper.dir/src/timekeeper.cpp.o
[ 0%] Building CXX object global/test/CMakeFiles/testglobal.dir/ForTestArchiving.cpp.o
[ 0%] Building CXX object mesh/test/CMakeFiles/testmesh.dir/data/inputs/gen2Dele.cpp.o
[ 0%] Building CXX object ode/test/CMakeFiles/testode.dir/odes/ParameterisedCvode.cpp.o
[ 1%] Linking CXX executable timekeeper
[ 1%] Built target timekeeper
Scanning dependencies of target testpde
[ 1%] Building CXX object pde/test/CMakeFiles/testpde.dir/pdes/SimpleUniformSourceParabolicPde.cpp.o
[ 1%] Linking CXX static library libtestmesh.a
[ 1%] Built target testmesh
Scanning dependencies of target testcell_based
[ 1%] Building CXX object cell_based/test/CMakeFiles/testcell_based.dir/simulation/OffLatticeSimulationWithMyStoppingEvent.cpp.o
In file included from /usr/lib/petscdir/petsc3.12/x86_64-linux-gnu-real/include/petscis.h:7,
from /usr/lib/petscdir/petsc3.12/x86_64-linux-gnu-real/include/petscvec.h:9,
from /home/gwqsz/chaste/Chaste_source_code/pde/src/problem/AbstractLinearParabolicPde.hpp:46,
from /home/gwqsz/chaste/Chaste_source_code/pde/test/pdes/SimpleUniformSourceParabolicPde.hpp:42,
from /home/gwqsz/chaste/Chaste_source_code/pde/test/pdes/SimpleUniformSourceParabolicPde.cpp:36:
/usr/lib/petscdir/petsc3.12/x86_64-linux-gnu-real/include/petscsys.h:169:6: error: #error "PETSc was configured with one OpenMPI mpi.h version but now appears to be compiling using a different OpenMPI mpi.h version"
169 | # error "PETSc was configured with one OpenMPI mpi.h version but now appears to be compiling using a different OpenMPI mpi.h version"
| ^~~~~
In file included from /usr/lib/petscdir/petsc3.12/x86_64-linux-gnu-real/include/petscis.h:7,
from /usr/lib/petscdir/petsc3.12/x86_64-linux-gnu-real/include/petscvec.h:9,
from /home/gwqsz/chaste/Chaste_source_code/cell_based/src/cell/properties/CellVecData.hpp:44,
from /home/gwqsz/chaste/Chaste_source_code/cell_based/src/cell/Cell.hpp:49,
from /home/gwqsz/chaste/Chaste_source_code/cell_based/src/population/AbstractCellPopulation.hpp:39,
from /home/gwqsz/chaste/Chaste_source_code/cell_based/src/population/killers/AbstractCellKiller.hpp:39,
from /home/gwqsz/chaste/Chaste_source_code/cell_based/src/simulation/AbstractCellBasedSimulation.hpp:45,
from /home/gwqsz/chaste/Chaste_source_code/cell_based/src/simulation/OffLatticeSimulation.hpp:39,
from /home/gwqsz/chaste/Chaste_source_code/cell_based/test/simulation/OffLatticeSimulationWithMyStoppingEvent.hpp:39,
from /home/gwqsz/chaste/Chaste_source_code/cell_based/test/simulation/OffLatticeSimulationWithMyStoppingEvent.cpp:36:
/usr/lib/petscdir/petsc3.12/x86_64-linux-gnu-real/include/petscsys.h:169:6: error: #error "PETSc was configured with one OpenMPI mpi.h version but now appears to be compiling using a different OpenMPI mpi.h version"
169 | # error "PETSc was configured with one OpenMPI mpi.h version but now appears to be compiling using a different OpenMPI mpi.h version"
| ^~~~~
In file included from /home/gwqsz/chaste/Chaste_source_code/mesh/src/reader/GenericMeshReader.hpp:47,
from /home/gwqsz/chaste/Chaste_source_code/mesh/src/common/AbstractTetrahedralMesh.hpp:54,
from /home/gwqsz/chaste/Chaste_source_code/mesh/src/common/TetrahedralMesh.hpp:49,
from /home/gwqsz/chaste/Chaste_source_code/cell_based/src/population/AbstractCellPopulation.hpp:59,
from /home/gwqsz/chaste/Chaste_source_code/cell_based/src/population/killers/AbstractCellKiller.hpp:39,
from /home/gwqsz/chaste/Chaste_source_code/cell_based/src/simulation/AbstractCellBasedSimulation.hpp:45,
from /home/gwqsz/chaste/Chaste_source_code/cell_based/src/simulation/OffLatticeSimulation.hpp:39,
from /home/gwqsz/chaste/Chaste_source_code/cell_based/test/simulation/OffLatticeSimulationWithMyStoppingEvent.hpp:39,
from /home/gwqsz/chaste/Chaste_source_code/cell_based/test/simulation/OffLatticeSimulationWithMyStoppingEvent.cpp:36:
/home/gwqsz/chaste/Chaste_source_code/mesh/src/reader/VtkMeshReader.hpp:55:10: fatal error: vtkDataArray.h: No such file or directory
55 | #include <vtkDataArray.h>
| ^~~~~~~~~~~~~~~~
compilation terminated.
make[3]: *** [cell_based/test/CMakeFiles/testcell_based.dir/build.make:63: cell_based/test/CMakeFiles/testcell_based.dir/simulation/OffLatticeSimulationWithMyStoppingEvent.cpp.o] Error 1
make[2]: *** [CMakeFiles/Makefile2:11184: cell_based/test/CMakeFiles/testcell_based.dir/all] Error 2
make[2]: *** Waiting for unfinished jobs....
[ 1%] Building CXX object ode/test/CMakeFiles/testode.dir/odes/ParameterisedOde.cpp.o
[ 1%] Linking CXX static library libtestglobal.a
[ 1%] Built target testglobal
make[3]: *** [pde/test/CMakeFiles/testpde.dir/build.make:63: **pde/test/CMakeFiles/testpde.dir/pdes/SimpleUniformSourceParabolicPde.cpp.o] Error 1
make[2]: *** [CMakeFiles/Makefile2:7748: pde/test/CMakeFiles/testpde.dir/all] Error 2
[ 1%] Linking CXX static library libtestode.a
[ 1%] Built target testode
make[1]: *** [CMakeFiles/Makefile2:1037: CMakeFiles/Continuous.dir/rule] Error 2
make: *** [Makefile:314: Continuous] Error 2**
I am a beginner and I really need your help.
Many thanks,
Guo Weiqi
Description
Issue when initialising DistributedBoxCollection in NodesOnlyMesh for Node based simulations.
Error when initialising NodesOnlyMesh using NodesOnlyMesh::ConstructNodesWithoutMesh()
If the corners of the box it tries to create are (2,2) and (200,200) it crashes.
Someone mentioned possibly the box size can't be a multiple of the interaction distance (I'm using 1.5).
But it might be a bit more complex because NodesOnlyMesh::SetUpBoxCollection() offsets the boundary by 1e-14 to ensure it's bigger.
Possible floating point precision error, but unlikely?
To Reproduce
Created minimal unit test which shows behaviour.
Test places 4 cells (one in each corner). Depending on their position can cause a "The point provided is outside all the boxes" exception from DistributedBoxCollection.
Similar error to Issue #22
Test is meant to go in src/test/mesh folder
/*
Copyright (c) 2005-2023, University of Oxford.
All rights reserved.
University of Oxford means the Chancellor, Masters and Scholars of the
University of Oxford, having an administrative office at Wellington
Square, Oxford OX1 2JD, UK.
This file is part of Chaste.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
* Neither the name of the University of Oxford nor the names of its
contributors may be used to endorse or promote products derived from this
software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
#ifndef TEST_NODES_ONLY_MESH_RECREATE_ERROR_HPP
#define TEST_NODES_ONLY_MESH_RECREATE_ERROR_HPP
#include <cxxtest/TestSuite.h>
#include <boost/archive/text_oarchive.hpp>
#include <boost/archive/text_iarchive.hpp>
#include <algorithm>
#include "SmartPointers.hpp"
#include "UblasCustomFunctions.hpp"
#include "NodesOnlyMesh.hpp"
#include "VtkMeshWriter.hpp"
#include "ArchiveOpener.hpp"
#include "PetscSetupAndFinalize.hpp"
class TestNodesOnlyMeshRecreateError : public CxxTest::TestSuite
{
private:
inline void runTest(double x1, double x2, double y1, double y2)
{
std::vector<Node<2>*> nodes;
nodes.push_back(new Node<2>(0, false, x1, y1));
nodes.push_back(new Node<2>(1, false, x1, y2));
nodes.push_back(new Node<2>(2, false, x2, y1));
nodes.push_back(new Node<2>(3, false, x2, y2));
NodesOnlyMesh<2> mesh;
mesh.ConstructNodesWithoutMesh(nodes, 1.5);
}
public:
void TestConstructSuccess()
{
runTest(0.0, 100.0, 0.0, 100.0);
runTest(2.0, 100.0, 2.0, 100.0);
runTest(0.0, 200.0, 0.0, 200.0);
runTest(3.0, 200.0, 4.0, 200.0);
}
void TestConstructFail2()
{
runTest(2.0, 200.0, 2.0, 200.0);
}
};
#endif /*TEST_NODES_ONLY_MESH_RECREATE_ERROR_HPP*/
Expected behavior
1st Test Passes.
2nd Test Fails with "The point provided is outside all the boxes" exception from DistributedBoxCollection
System
Chaste Build Info:
<ChasteBuildInfo>
<ProvenanceInfo>
<VersionString>2021.1.61ed00c</VersionString> <!-- build specific -->
<IsWorkingCopyModified>1</IsWorkingCopyModified>
<BuildInformation>Release</BuildInformation>
<BuildTime>Mon, 10 Oct 2022 11:14:10 +0000</BuildTime>
<CurrentTime>Mon, 24 Apr 2023 12:21:20 +0000</CurrentTime>
<BuilderUnameInfo>Linux</BuilderUnameInfo>
</ProvenanceInfo>
<Compiler>
<NameAndVersion>/usr/bin/c++, version 11.2.0</NameAndVersion>
<Flags>-std=c++14 -Wall -Wnon-virtual-dtor -Woverloaded-virtual -Wextra -Wno-unused-parameter -Wvla -Wimplicitfallthrough=2 -O3 -DNDEBUG</Flags>
</Compiler>
<Libraries>
<CompiledIn>
<PETSc>3.12.0</PETSc>
<Boost>1.71.0</Boost>
<HDF5>1.10.0</HDF5>
<Parmetis>4.0.3</Parmetis>
</CompiledIn>
<Binaries>
<XSD>4.0.0</XSD>
</Binaries>
<Optional>
<SUNDIALS>2.5.0</SUNDIALS><!-- includes Cvode of a different version number -->
<VTK>9.2</VTK>
<Xerces>3.2.0</Xerces>
</Optional>
</Libraries>
<ChasteCodegenVersion>chaste_codegen 0.9.12</ChasteCodegenVersion>
</ChasteBuildInfo>
Describe the bug
Boost Filesystem fails to copy between volumes. This is a known Boost bug: https://stackoverflow.com/questions/24209886/invalid-cross-device-link-error-with-boost-filesystem
To Reproduce
This may be specific to Boost 1.74.0 with /tmp and /home on different volumes:
jmpf@csu15256:~/Workspace/Chaste/build$ df /tmp/
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/nvme0n1p2 490617784 404090124 61532180 87% /
jmpf@csu15256:~/Workspace/Chaste/build$ df /home
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/nvme1n1p1 491133848 330703932 135408220 71% /home
ctest -VV -R TestFileFinder
...
13: Entering TestFindMatches
13: Passed
13: Entering TestCopying
13:
13: /home/jmpf/Workspace/Chaste/global/test/TestFileFinder.hpp:362: Error: Test failed:
13: Chaste error: ./global/src/FileFinder.cpp:332: boost::filesystem::copy_file: Invalid cross-device link: "/home/jmpf/Workspace/Chaste/global/test/TestFileFinder.hpp", "/tmp/jmpf/testoutput/TestFileFinder_TestCopying/TestFileFinder.hpp"
13: Failed
13: Entering TestDefaultConstructor
13: Passed
Workaround
Change environment variable to give a different output location
export CHASTE_TEST_OUTPUT="/home/jmpf/tmp-chaste/"
Expected behaviour
Test should pass
System
Please provide relevant details of your system, such as:
We would like to add a few new examples of cell-based functionality to the trunk. These include:
This issue continues the discussion for legacy trac ticket 3098:
AlexFletcher created the following ticket on 2022-04-28 at 08:47:02, it is owned by AlexFletcher
Modify setup_project.py to rename TestHello to something like TestHello_[MyProjectName], just to reduce the chance of this happening in future? (Though if someone just copies the template user project directly and doesn't run setup_project.py then this wouldn't help them.)
See also (trac ticket 2857). https://github.com/Chaste/trac_archive/blob/master/issues/2857.md
See #50. Tutorials are currently uploaded to wiki - plan is to move these to the website instead
I just tried to download Chaste. The page that pops up (https://www.cs.ox.ac.uk/chaste/download.html) has a section at the bottom stating:
"Redirect to GitHub
Please see the tagged release on GitHub and download from there. Thank you."
I get a 404 on the link it provides. I think the correct link is: https://github.com/Chaste/Chaste/releases/tag/release_2019.1
This issue addresses the following legacy tickets:
Support for these boost versions has been added in PR #27.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.