This pulls in the work from the following tickets #3077 #3078 #3079 #2087

Continuous testa and coverage pass https://chaste.cs.ox.ac.uk/buildbot/Nightly%20Coverage/coverage1573/

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?

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

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

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.

Summary

This adds support for boost 1.78 to Chaste for ticket 3094.

Passing Tests

• [x] Continuous
• [x] Nightly
• [x] Parallel

Failing Tests

• ~~TestArchivingHelperClasses~~ (Fixed)
• ~~TestArchivingHelperClassesParallel~~ (Fixed)

Additional Testing

Boost 1.75

• [x] Continuous
• [x] Nightly
• [x] Parallel

Boost 1.76

• [x] Continuous
• [x] Nightly
• [x] Parallel

Boost 1.77

• [x] Continuous
• [x] Nightly
• [x] Parallel

Notes

• TestGenerateSteadyStateCrypt in Weekly test pack currently passes for intel, but fails for gcc regardless of boost version. All other Weekly tests pass for gcc.

This class finds the steady state behaviour of an action potential model. This is done by using linear regression on the state variables when it looks like we have exponential decay.

TestSteadyStateExtrapolationRunner.hpp provides an example which uses this class.

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.

Summary

This issue addresses the following legacy tickets:

• 3061 - Support Boost 1.75
• 3073 - Support Boost 1.76
• 3074 - Support Boost 1.77
• 3094 - [BBR WP2] Support Boost 1.78

Support for these boost versions has been added in PR #27.

This archive was causing Portability_3_Wed (Boost 1.66 and CVODE=OFF) to fail. Archive has been recreated with Boost 1.58 (oldest tested) and CVODE=OFF.

Description

This upgrades the minimum version of chaste_codegen to 0.9.10 for Sundials 6.0 support.

Context

• This change is related to Chaste ticket #3084
• The chaste_codegen project has been updated to generate Chaste code that supports Sundials 6.0.

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Testing

• [ ] Testing is done automatically and codecov shows test coverage
• [ ] This cannot be tested automatically
• [x] This can be tested automatically, but requires Sundials 6.0.0 to be installed. It has been tested manually in a chaste-docker container. The following tests all passed:
  • Continuous
  • Nightly
  • Codegen
  • project_ApPredict
  • Weekly (except TestGenerateSteadyStateCrypt, which already fails)

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.

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:

• OS version
• CMake version
• C++ compiler version
• Python version
• Relevant Chaste dependency versions e.g. PETSc, Boost, Sundials etc.

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 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).

I'm against using Biostars:

Biostars looks reasonable, but I have the following thoughts:

• It does not appear to be under active development any longer; only five commits in the last year: GitHub page
• Any system running locally on a machine in Oxford would go against the strategic plan of decentralising Chaste now that the developers are distributed around the world
• It would be another service that someone would have to be responsible for knowing how to fix, upgrade, etc.

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.

GitHub instead?

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:

GitHub issues: how would it work?

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

Next steps

My feeling is that this is an improvement on the mailing list, and does not require setting up anything new.

Are there:

• Any features we would want that this does not offer
• Any other cons to using GitHub issues
• Anyone hugely in favour of sticking with the original plan of something Biostars-esque?

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:

• votes,
• the best answer at the top so you don't have to read the whole correspondence,
• the ability for us to edit answers things change over time,

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:

• We already use it
• It's almost certainly going to be around longer than Chaste
• It's the de facto standard place for people to ask questions about the software hosted there

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:

• Letting q2a check users/passwords against tracs database
• Letting q2a get email addresses from tracs database
• Letting q2a create new users -or- letting it redirect to a trac page instead

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:

• Getting the usernames/pwhashes from a file (easy)
• Redirecting registration requests (easy, but a bit annoying as users will be redirected, then need to register, then need to go back to q2a and login)
• Getting email addresses from trac's database (could be tricky, probably fine)

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!

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

• /var/log/dsmsched.log (which records all transactions) is backed up
• backups launched via crontab send a record of all transactions to root@chaste

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

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:

• Svn -> Git: Remove all references to accessing the svn repo
• CMake -> Scons: Indicate that CMake is now preferred, but that Scons is deprecated but still working

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.

• GettingStarted (update figure etc.)
• ChasteGuides (remove info on cardiac executable?)
  • ChasteGuides/HostconfigSystem (new guide for when cmake doesn't pick them up?)
  • ChasteGuides/RunningFirstTests
  • ChasteGuides/VisualisationGuides/CombineConsecutiveSimulations
  • ChasteGuides/RunningAcceptanceTests (may not be necessary - see [trac ticket 2908])
  • ChasteGuides/RunningBinariesFromCommandLine
• InstallGuides/InstallGuide (bottom bit).
• InstallGuides/Arc#GettingChaste
• MakingARelease
• UserTutorials (scons at the top)
• Something on building executables in apps folders (moved scons instructions to SconsArchive/BuildingCardiacExecutable - which also applied to projects etc.)
• The 'default repository' on here https://chaste.cs.ox.ac.uk/trac/browser is confusing since it is the old defunct one. I have navigated to out of date trunk files by looking at it a few times.
• These files needs updating: *https://chaste.cs.ox.ac.uk/trac/browser/git_repo/projects/README should probably point at a relevant wiki page.
  • https://chaste.cs.ox.ac.uk/trac/browser/git_repo/README.txt

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?)

  • There is already extensive information on how to specify dependency locations, in the ChasteGuides/CmakeBuildGuide, so I think this can be considered done too.

• Something on building executables in apps folders (moved scons instructions to SconsArchive/BuildingCardiacExecutable - which also applied to projects etc.)

  • Also already in the ChasteGuides/CmakeBuildGuide (here), so also considered done.

• MakingARelease

  • Need to decide which bits to keep, and which bits to remove. Perhaps worth a dedicated ticket?

• InstallGuides/Arc#GettingChaste

  • Could do with someone in a position to fiddle with this. Maybe James Grogan?

Comment by mirams on 2017-06-01 at 10:40:31

I think the information on:

• setting up dependency locations
• building executables
• running acceptance tests on executables

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 (change rXXXX 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 (change rXXXX 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).

This issue continues the discussion for legacy trac ticket 3083:

AlexFletcher created the following ticket on 2021-12-10 at 10:29:15, it is owned by AlexFletcher

Moving the primary Chaste website to GitHub.

One option is to use GitHub Pages.

Fergus had some thoughts about this.

Comment by jmpf on 2022-01-27 at 10:38:28

As the sole maintainer of the website I'm keen to replace all the existing pages with a redirection. Then I won't have to remember how to maintain them.

Comment by fcooper8472 on 2022-01-27 at 12:15:33

Current plan is to build a Hugo (https://gohugo.io/) static website hosted on GitHub pages at the address https://chaste.github.io/

We would need to pick a theme, examples here: https://themes.gohugo.io/

Something like: https://themes.gohugo.io/themes/doks/ https://themes.gohugo.io/themes/hugo-geekdoc/

would be appropriate.

Comment by AlexFletcher on 2022-01-27 at 13:45:59

Let's go with doks for now, and can always change depending on everyone's preference.