openCARP issueshttps://git.opencarp.org/groups/openCARP/-/issues2019-10-10T15:40:26Zhttps://git.opencarp.org/openCARP/openCARP/-/issues/2Streamline commandline user interfaces2019-10-10T15:40:26ZAxel Loeweaxel.loewe@kit.eduStreamline commandline user interfacesPrM vs gengetopt (- vs. --)
Probably easiest to adapt PrM such that it accepts both "-" and "--"PrM vs gengetopt (- vs. --)
Probably easiest to adapt PrM such that it accepts both "-" and "--"Usability sufficientJorge SanchezJorge Sanchezhttps://git.opencarp.org/openCARP/openCARP/-/issues/80Limpet Metadata extension2024-03-14T12:13:25ZAxel Loeweaxel.loewe@kit.eduLimpet Metadata extension* [ ] Add fields for species and location
* [ ] Output condensed metadata with `--list-imps` (in a table?)
* [ ] Output full metadata with `--imp-info` (in a table?)
* [x] Fix doi output (interpreted as a floating point number).* [ ] Add fields for species and location
* [ ] Output condensed metadata with `--list-imps` (in a table?)
* [ ] Output full metadata with `--imp-info` (in a table?)
* [x] Fix doi output (interpreted as a floating point number).Ionic model library overhaulJorge SanchezJorge Sanchez2022-02-16https://git.opencarp.org/openCARP/openCARP/-/issues/33EnSight output2022-02-04T12:40:00ZAxel Loeweaxel.loewe@kit.eduEnSight outputWe could think about providing output directly in the EnSight format. It's was recently implemented in meshtool and could be transferred to the openCARP I/O writer classWe could think about providing output directly in the EnSight format. It's was recently implemented in meshtool and could be transferred to the openCARP I/O writer classFuture Implementaionshttps://git.opencarp.org/openCARP/openCARP/-/issues/355openMP does not scale for utilities2024-03-26T07:43:08ZTomas Starytomas.stary@kit.eduopenMP does not scale for utilitiesSomeone pointed out that openMP does not work for igbutils:
https://opencarp.org/q2a/1222/precompiled-binaries-igbutils-with-openmp
As discussed in the Dev Meeting, there is only a single openMP switch in the configuration, which might...Someone pointed out that openMP does not work for igbutils:
https://opencarp.org/q2a/1222/precompiled-binaries-igbutils-with-openmp
As discussed in the Dev Meeting, there is only a single openMP switch in the configuration, which might sometime lead even to increased time to the simulation.
One suggestion was to include two openMP switches -- one for utilities and one for the simulator.
I'm not sure about the details of the possible implementation. Please comment if you could provide better explanation of what is required.https://git.opencarp.org/openCARP/openCARP/-/issues/354Single precision floating point numbers for LIMPET2024-03-26T09:11:04ZAtoli HuppeSingle precision floating point numbers for LIMPETI have been investigating using single precision (f32) numbers for LIMPET computations. This could offer significant speedups to the cost of reduced numerical precision.
I tried two things:
- Store only lookup tables (LUTs) as f32, mea...I have been investigating using single precision (f32) numbers for LIMPET computations. This could offer significant speedups to the cost of reduced numerical precision.
I tried two things:
- Store only lookup tables (LUTs) as f32, meaning only LUT interpolation is done with f32, everything else is f64. Speedup in blue on the bar plot compared to baseline (everything on f64). Potential
- Store LUTs as f32 and state variables as f32 as well. This means almost all operations can be done using f32 instructions. Speedup in red on the bar plot.
A working version of openCARP with f32 limpet enabled by default is available on the branch [lut-f32-inmemory](https://git.opencarp.org/openCARP/openCARP/-/tree/lut-f32-inmemory?ref_type=heads). Needs to be built with MLIR.
I attached to this post a PDF with plots of the potential over time for each model, comparing the output for baseline (all f64), only LUTs f32 and both LUTs and state variables f32.
The speedup is very interesting for some models and the error seems acceptable for most models. There are a few ways this could be integrated to opencarp: a runtime switch for the user (meaning we would have to compile all versions f32/f64, making the build process heavier) or enable f32 only for some models (maybe with a switch in easyML).
I think it depends mostly on how acceptable the error is. Maybe @axel.loewe @edward.vigmond you have an idea what direction we could go?
These are the speedups I get using `bench` with 1000 cells for 1000 ms with a time step of 0.01. The benchmarks were ran on a single core with AVX512 (16 floats per vector operation).
```bash
bench --bin --validate --no-trace -I <Model> -n 1000 -a 1000
```
![limpet-speedup-f32](/uploads/46be156cbd2f8e8cf46ce0c9219f9966/limpet-speedup-f32.png)
[limpet.pdf](/uploads/07ca0ec0ca407cba23e8eaf16c1a1e25/limpet.pdf)https://git.opencarp.org/openCARP/openCARP/-/issues/353OHara model - minor comments by Michael Clerx2024-03-25T06:47:50ZEike M. WülfersOHara model - minor comments by Michael ClerxHi all,
Michael recently published some comments on the OHara model:
https://docs.google.com/document/d/111fqNzQGvGAjB_PrkvejEhzqwROrR6czz_OBz7Ep-iM/edit#heading=h.q1i97y5bekil
He points out that the calculation of `x1` is slightly wro...Hi all,
Michael recently published some comments on the OHara model:
https://docs.google.com/document/d/111fqNzQGvGAjB_PrkvejEhzqwROrR6czz_OBz7Ep-iM/edit#heading=h.q1i97y5bekil
He points out that the calculation of `x1` is slightly wrong in the original publication.
openCARP's implementation has the same error:
https://git.opencarp.org/openCARP/openCARP/-/blob/master/physics/limpet/models/OHara.model?ref_type=heads#L598
He also suggests a possible optimization for Jnak, reducing the E_x computation a bit.
Additionally (depending on units), the H+ concentration might be wrong, too.
https://git.opencarp.org/openCARP/openCARP/-/blob/master/physics/limpet/models/OHara.model?ref_type=heads#L580
Fortunately, these errors seem to be of little consequence – well, unfortunate for us, because we are still chasing the steady-state of the model in openCARP ;(https://git.opencarp.org/openCARP/openCARP/-/issues/352Build fails with clang-162024-03-25T13:29:06ZyuriBuild fails with clang-16See the log [here](https://freebsd.org/~yuri/opencarp-14.0-errors.txt).
Version: 14.0
clang-16
FreeBSD 14.0 STABLESee the log [here](https://freebsd.org/~yuri/opencarp-14.0-errors.txt).
Version: 14.0
clang-16
FreeBSD 14.0 STABLEhttps://git.opencarp.org/openCARP/FACILE-RS/-/issues/1Use registry rather than webserver for storing artifacts2024-03-08T12:53:31ZAxel Loeweaxel.loewe@kit.eduUse registry rather than webserver for storing artifactsHi,
When adapting the [openCARP FACILE-RS configuration](https://git.opencarp.org/openCARP/openCARP/-/blob/master/.gitlab-ci.yml?ref_type=heads) for a related project, I got the impression that we are using the Gitlab registry for most o...Hi,
When adapting the [openCARP FACILE-RS configuration](https://git.opencarp.org/openCARP/openCARP/-/blob/master/.gitlab-ci.yml?ref_type=heads) for a related project, I got the impression that we are using the Gitlab registry for most of the things we want to store while others go on the webserver.
For doxygen, the manual and the HTML parameters, I think the web server is the best place as they are small and directly incorporated into the website.
For Docker and the Bags, I was wondering if it would be better to use the registry.
```
DOCKER_ARCHIVE_DESTINATION: 'opencarp@sulmass.scc.kit.edu:/var/www/docker/'
DOCKER_ARCHIVE_URL: 'https://opencarp.org/docker'
BAG_DESTINATION: 'opencarp@sulmass.scc.kit.edu:/var/www/bags/'
```Jochen Klarmail@jochenklar.deJochen Klarmail@jochenklar.dehttps://git.opencarp.org/openCARP/openCARP/-/issues/348Dockerfile for the arm64 architecture2024-03-13T07:58:16ZTomas Starytomas.stary@kit.eduDockerfile for the arm64 architectureAs pointed out by @gunnar.seemann the opencarp docker image is only available for x86_64 architecture which makes it run much slower on the increasingly popular arm64 CPUs. We have just tested the build on arm64 with @joshuasteyer. It wa...As pointed out by @gunnar.seemann the opencarp docker image is only available for x86_64 architecture which makes it run much slower on the increasingly popular arm64 CPUs. We have just tested the build on arm64 with @joshuasteyer. It was sucessfull but the performance not compared yet.
It would be nice to support at least arm64 architecture in addition to x86_64 as using the containers makes the onboarding of new users and developers much smoother.
Here are some resources which might be useful:
https://docs.docker.com/build/building/multi-platform/
https://github.com/tonistiigi/binfmt
Also, to enable the installation of container environment on MacOS the following procedure can be used:
```
brew install colima docker
colima start --cpu 8 --memory 8
docker ps
```
when there is not enough memory, the compilation might fail.
(cc @ml0401)https://git.opencarp.org/openCARP/openCARP/-/issues/345Add precomputation or GPU version for stimuli and clamp_vm in electrics.cc2024-03-27T13:13:51ZVincent AlbaAdd precomputation or GPU version for stimuli and clamp_vm in electrics.cc### Problem to solve with the new feature
Currently, during executions on bench or opencarp, when using GPUs for the solver and limpet,
data needs to be sent back to the CPUs before every stimulus or clamp_vm event.
This becomes a major...### Problem to solve with the new feature
Currently, during executions on bench or opencarp, when using GPUs for the solver and limpet,
data needs to be sent back to the CPUs before every stimulus or clamp_vm event.
This becomes a major bottleneck for performance during GPU execution.
### Intended users
Unknown
### Further details
This feature request addresses the issue discussed during the WP1 meeting on 27 November,
Currently, stimuli and the clamp_vm function only have a CPU implementation.
Pre-computing them at the start of the simulation or having a GPU implementation (or both)
Would allow to remove the need for most CPU-GPU data transfer during computation, improving performance
### Proposal
Hi,
It was mentioned in the last few meetings that it should be possible to precompute the stimuli,
It should be possible to send the precomputation results to the GPUs to apply them during a given time step.
Please let me know if you have any further questions about the issue,
Thank you!
### Testing
Results for computation using precomputed stimuli need to be the same as doing the same computation
using the current implementation.
### Links / references
None for nowTomas Starytomas.stary@kit.eduTomas Starytomas.stary@kit.eduhttps://git.opencarp.org/openCARP/openCARP/-/issues/342Continuous Benchmarking (CB): new tests and getting the results2024-03-01T10:29:44ZTomas Starytomas.stary@kit.eduContinuous Benchmarking (CB): new tests and getting the results@huppe is working on developing new benchmarking for single-cell models.
Currently the CB pipelines are setup in `.gitlab/ci/cb.gitlab-ci.yml`.
@ntippman what is the way for us to access the results of the tests? I haven't find the cod...@huppe is working on developing new benchmarking for single-cell models.
Currently the CB pipelines are setup in `.gitlab/ci/cb.gitlab-ci.yml`.
@ntippman what is the way for us to access the results of the tests? I haven't find the code or documentation for the setup of the infrastructure where the tests run.
Thank you!https://git.opencarp.org/openCARP/openCARP/-/issues/341phase singularity processing (GlFilament)2023-11-07T09:55:11ZMoritz Linderphase singularity processing (GlFilament)https://git.opencarp.org/openCARP/openCARP/-/issues/340conditional simulation2023-11-07T09:54:45ZMoritz Linderconditional simulationhttps://git.opencarp.org/openCARP/openCARP/-/issues/339LAT on subset of nodes2023-11-07T09:54:14ZMoritz LinderLAT on subset of nodeshttps://git.opencarp.org/openCARP/openCARP/-/issues/337Update for the base docker image2024-03-12T14:18:41ZTomas Starytomas.stary@kit.eduUpdate for the base docker imageThere is a need for the python3.9 within the docker container, as @gunnar.seemann is planning to test [jupyterquiz](https://github.com/jmshea/jupyterquiz) that requires at least that version of python. Currently we have another image bui...There is a need for the python3.9 within the docker container, as @gunnar.seemann is planning to test [jupyterquiz](https://github.com/jmshea/jupyterquiz) that requires at least that version of python. Currently we have another image build `FROM docker.opencarp.org/opencarp/opencarp:latest`
That image is are build `FROM ubuntu:20.04`, which seam to install version 3.8.10. by default, but after running `apt update` the python3.9 is available for installation too. Just updating python to the next minor version shouldn't break anything.
@m.houillon would you like to take care of it (as you are the maintainer mentioned in the Dockerfiles)? (Otherwise feel free to assign it to me.)Marie HouillonMarie Houillon2023-11-30https://git.opencarp.org/openCARP/openCARP/-/issues/336distribute mesh w.r.t tags and geometry based on scotch/pt-scotch2023-11-14T12:52:40ZFatemeh Cheginidistribute mesh w.r.t tags and geometry based on scotch/pt-scotchHi Wissam,
We currently distribute mesh w.r.t only the tags. We would like to distribute the mesh based on __tags and geometry__ to reduce the communication. Yves suggested using __scotch/pt-scotch__:
To do so:
- Please pull the branc...Hi Wissam,
We currently distribute mesh w.r.t only the tags. We would like to distribute the mesh based on __tags and geometry__ to reduce the communication. Yves suggested using __scotch/pt-scotch__:
To do so:
- Please pull the branch called __emi_model__
- to compile the current branch openCarp folder-> __cmake --build _build --target install__
- and then go to ..../openCARP/test/emi, and run __mpiexec -n 3 openCARP +F parameters.par__
- to make any change, please create a separate branch and replace __distribute_elements_based_tags__ with your own function in __electrics.cc__
If you have any questions, let us know. @wissambouymedj @tomas.stary
[Fatemeh_wp3_EMI_openCARP.pdf](/uploads/10fc98feed17525584cbaf74674a2408/Fatemeh_wp3_EMI_openCARP.pdf)
Best,
Fatemehwissambouymedjwissambouymedjhttps://git.opencarp.org/openCARP/openCARP/-/issues/329Scale bar / dimensions in Meshalyzer2023-08-28T14:35:32ZGunnar SeemannScale bar / dimensions in Meshalyzerhttps://git.opencarp.org/openCARP/openCARP/-/issues/328Numerical scheme guidance2023-08-28T14:34:37ZGunnar SeemannNumerical scheme guidancehttps://git.opencarp.org/openCARP/openCARP/-/issues/327Better Mesher and Meshtool documentation2023-08-28T14:33:31ZGunnar SeemannBetter Mesher and Meshtool documentationhttps://git.opencarp.org/openCARP/openCARP/-/issues/326Docker file for MLIR2023-08-28T14:32:14ZGunnar SeemannDocker file for MLIR