dune-copasi issueshttps://gitlab.dune-project.org/copasi/dune-copasi/-/issues2024-03-27T12:32:58Zhttps://gitlab.dune-project.org/copasi/dune-copasi/-/issues/90Add versioning to Wasm in the web documentation2024-03-27T12:32:58ZSantiago Ospina De Los Ríossospinar@gmail.comAdd versioning to Wasm in the web documentationIn !190 I forked what will be the documentation for version 2.0.0. The `try.md` document under that fork is still using the latest version. Would it be possible for freeze the `WasmInterface` on a given version?
Maybe something like thi...In !190 I forked what will be the documentation for version 2.0.0. The `try.md` document under that fork is still using the latest version. Would it be possible for freeze the `WasmInterface` on a given version?
Maybe something like this?
```jsx
<WasmInterface version="2.0.0" .../>
```
(assuming that there is a released version 2.0.0 in the npm repository)Joseph HoltenJoseph Holtenhttps://gitlab.dune-project.org/copasi/dune-copasi/-/issues/85Parafield is being installed with dune-copasi2024-02-20T21:22:57ZSantiago Ospina De Los Ríossospinar@gmail.comParafield is being installed with dune-copasiThe parafields dependency is being installed with dune copasi as if it was from this project (see https://gitlab.dune-project.org/copasi/dune-copasi/-/jobs/555708#L500). This should not be like this by default.The parafields dependency is being installed with dune copasi as if it was from this project (see https://gitlab.dune-project.org/copasi/dune-copasi/-/jobs/555708#L500). This should not be like this by default.https://gitlab.dune-project.org/copasi/dune-copasi/-/issues/84SymEngine fails with seg-fault when the wrong keyword is added2024-02-20T15:11:17ZSantiago Ospina De Los Ríossospinar@gmail.comSymEngine fails with seg-fault when the wrong keyword is addedIf a keyword is used but is not know to the parser, SymEngine fails with a segmentation fault. The expected behavior is to report the unknown keyword as an exception. Example:
```ini
[model.scalar_field.B]
compartment = domain
cross_dif...If a keyword is used but is not know to the parser, SymEngine fails with a segmentation fault. The expected behavior is to report the unknown keyword as an exception. Example:
```ini
[model.scalar_field.B]
compartment = domain
cross_diffusion.A.expression = 0.4
reaction.expression = A*B*1e-06*-100.0
reaction.jacobian.A.expression = B*1e-06*-100.0
reaction.jacobian.B.expression = A*1e-06*-100.0
storage.expression = 1
initial.expression = 1000*B_initialConcentration(x,y)
```
`x` is supposed to be `position_x`. But the executable fails to report thishttps://gitlab.dune-project.org/copasi/dune-copasi/-/issues/75Setup Code coverage report2021-05-10T12:58:33ZSantiago Ospina De Los Ríossospinar@gmail.comSetup Code coverage report### Description
So far, tests are either passed or not. Code coverage also give some insights of where code should be more tested.
### Proposal
Add code coverage to make tests and report to gitlab or github, whatever is easier.
### How...### Description
So far, tests are either passed or not. Code coverage also give some insights of where code should be more tested.
### Proposal
Add code coverage to make tests and report to gitlab or github, whatever is easier.
### How to test the implementation?
We can assess the coverage quality in a given merge request/branche.
### Related issues
See #8
<!--
PLEASE READ THIS
Briefly explain __what__ should be changed and __propose__ how this can happen.
Adding pseudo code or diagrams would be great!
Additionally, you can:
- add suitable labels
- assign a milestone
- mention other issues
-->Santiago Ospina De Los Ríossospinar@gmail.comSantiago Ospina De Los Ríossospinar@gmail.comhttps://gitlab.dune-project.org/copasi/dune-copasi/-/issues/42Move dependencies from forks to original repositories2023-09-28T07:27:24ZSantiago Ospina De Los Ríossospinar@gmail.comMove dependencies from forks to original repositories### Description
Some of the dependencies are from a fork in the GitLab `COPASI` namespace. This is not optimal because all of these repositories evolve and is hard to keep track of the new updates together with the custom changes that we...### Description
Some of the dependencies are from a fork in the GitLab `COPASI` namespace. This is not optimal because all of these repositories evolve and is hard to keep track of the new updates together with the custom changes that we have made
### Proposal
Move fork changes to original modules with Merge Requests and update our dependencies to it:
- [x] ~~`dune-logging`~~
- [x] ~~`fork` in sync with `origin`~~
- [x] ~~Send merge request from `fork` to `origin`~~
- [x] ~~`origin` accepted merge request into `origin/master`~~
- [x] ~~`origin` has a new release~~
- [x] ~~Update `dune-copasi` dependecy into the last `origin` release~~
- [x] `dune-multidomaingrid`
- [x] ~~`fork` in sync with `origin`~~
- [x] Send merge request from `fork` to `origin`
- [x] `origin` accepted merge request into `origin/master`
- [ ] `origin` has a new release
- [ ] Update `dune-copasi` dependecy into the last `origin` release
- [x] `dune-typetree`
- [x] ~~`fork` in sync with `origin`~~
- [x] Send merge request from `fork` to `origin`
- [x] `origin` typetreeaccepted merge request into `origin/master`
- [ ] `origin` has a new release
- [ ] Update `dune-copasi` dependecy into the last `origin` release
- [x] `dune-pdelab`
- [x] ~~`fork` in sync with `origin`~~
- [x] Send merge request from `fork` to `origin`
- [ ] `origin` accepted merge request into `origin/master`
- [ ] `origin` has a new release
- [ ] Update `dune-copasi` dependecy into the last `origin` release
### How to test the implementation?
CI is smoothly working with original repositories instead of custom forks.
### Related issues
See:
* https://gitlab.dune-project.org/staging/dune-typetree/-/merge_requests/55
* https://gitlab.dune-project.org/staging/dune-typetree/-/merge_requests/86
* https://gitlab.dune-project.org/staging/dune-typetree/-/merge_requests/85
<!--
PLEASE READ THIS
Briefly explain __what__ should be changed and __propose__ how this can happen.
Adding pseudo code or diagrams would be great!
Additionally, you can:
- add suitable labels
- assign a milestone
- mention other issues
-->ES2 - Final software releaseSantiago Ospina De Los Ríossospinar@gmail.comSantiago Ospina De Los Ríossospinar@gmail.comhttps://gitlab.dune-project.org/copasi/dune-copasi/-/issues/38Branch off custom dependencies2021-02-10T22:37:44ZSantiago Ospina De Los Ríossospinar@gmail.comBranch off custom dependencies### Description
For the next release, it is important to keep fixed tags where the user may encounter reproducible builds. The current approach keeps depending on the `HEAD` of the `support/copasi` branch.
### Proposal
Branch off depend...### Description
For the next release, it is important to keep fixed tags where the user may encounter reproducible builds. The current approach keeps depending on the `HEAD` of the `support/copasi` branch.
### Proposal
Branch off dependent modules for the next `DuneCopasi` release
### How to test the implementation?
Changing the CI to use these new branches.
<!--
PLEASE READ THIS
Briefly explain __what__ should be changed and __propose__ how this can happen.
Adding pseudo code or diagrams would be great!
Additionally, you can:
- add suitable labels
- assign a milestone
- mention other issues
-->ES2 - Final software releaseSantiago Ospina De Los Ríossospinar@gmail.comSantiago Ospina De Los Ríossospinar@gmail.comhttps://gitlab.dune-project.org/copasi/dune-copasi/-/issues/16Add IO for refined grids2021-02-10T22:38:03ZSantiago Ospina De Los Ríossospinar@gmail.comAdd IO for refined grids### Description
The current `model_state` encodes the majority of the information that is needed to store and recover simulations. However, it cannot be written or read to make checkpoints in the simulation. This is may be inconvenient f...### Description
The current `model_state` encodes the majority of the information that is needed to store and recover simulations. However, it cannot be written or read to make checkpoints in the simulation. This is may be inconvenient for long simulations. Achieving this is not an easy task because the grid may change during the simulation: Although it is possible to write and read a refined grid, it woudln't be possible to later coarse the grid again.
### Proposal
Try to recover `mode_state` grid by
1. Writing the refined grid.
2. Read the coarse grid and the refined grid.
3. Refine coarse grid until every entity has the same volume for the two grids.
4. Check that number of entities is correct with respect to the refined one.
5. Check that the two grids have the same index set.
6. Read GFS and coefficient vector from other file (This may go in another issue).
6. Use new refined to continue simulation.
### How to test the implementation?
Recover grid from and old simulation and check that 4 and 5 pass.
### Related issues
See #
<!--
PLEASE READ THIS
Briefly explain __what__ should be changed and __propose__ how this can happen.
Adding pseudo code or diagrams would be great!
Additionally, you can:
- add suitable labels
- assign a milestone
- mention other issues
-->ES2 - Final software releaseSantiago Ospina De Los Ríossospinar@gmail.comSantiago Ospina De Los Ríossospinar@gmail.comhttps://gitlab.dune-project.org/copasi/dune-copasi/-/issues/14Add virtual refinement for VTK output2021-02-10T22:38:08ZSantiago Ospina De Los Ríossospinar@gmail.comAdd virtual refinement for VTK output### Description
Right now, we only write data at the vertices of the triangulation, this naturally correspond to first order polynomial finite elements. Since vtk does not ha a good way to write arbitrary polynomial order and/or is not c...### Description
Right now, we only write data at the vertices of the triangulation, this naturally correspond to first order polynomial finite elements. Since vtk does not ha a good way to write arbitrary polynomial order and/or is not convenient for a software like dune, we opt for the old option to fake local refinement in order to attach more data to a single real entity.
### Proposal
Add and option in the configuration file to set the virtual refinement level and use the `SubsamplingVTKWriter` provided by `dune-grid` which was specifically made for this task.
### How to test the implementation?
Write a python wrapper that checks that higher virtual refinement level produces bigger files for the first step.
### Related issues
See #13
<!--
PLEASE READ THIS
Briefly explain __what__ should be changed and __propose__ how this can happen.
Adding pseudo code or diagrams would be great!
Additionally, you can:
- add suitable labels
- assign a milestone
- mention other issues
-->ES2 - Final software releaseSantiago Ospina De Los Ríossospinar@gmail.comSantiago Ospina De Los Ríossospinar@gmail.com