Torso model intra and extra regions are incorrectly written using gridout

Question

Good day everyone,

I am currently using some torso meshes from the CEMRG database(https://zenodo.org/records/7253863) found under our modeling resources page. For reference, I am using KCL_torso1. When I attempt a bidomain simulation and write the intra and extra meshes using the gridout option, I see that the resulting meshes are very spiky and jagged. In addition, there is a new tissue region '0' which I assume is automatically created in the process. 

My question is, will this affect the accuracy of the bidomain simulation, and how should I fix this phenomenon? Thank you.

Lucas

Answer 1

I'm not familiar with all meshes mentioned on the community resources page. Can you confirm that you only see these characteristics of the mesh once you passed it through openCARP or are they already present in the input mesh?

Comments

Hi Axel, the problem is caused only after passing through openCARP. For example, some individual vertices are located at a long distance outside of the original torso boundary. I wish I could post a screenshot but unfortunately I don't know how.

---

Unfortunately, images can only be added to questions and not to comments. The easiest is likely to upload the screenshot to Google Drive or similar and then sharing a public link here.

---

Great suggestion - hopefully these links will work:

Normal torso: https://drive.google.com/file/d/1vzZDCejfwnYfucc3_o5FbKhLWlkhTwdZ/view?usp=drive_link

Intra: https://drive.google.com/file/d/10fqFwpBF6Z7_Lw0G5y_N9_JlXg0kDSLx/view?usp=drive_link

Extra: https://drive.google.com/file/d/1JeMcvLZhvaylzj2j-f8d5EYjjMkaQgvt/view?usp=drive_link

Also, should you wish to reproduce this issue, I attach a minimal example of my parameter file as well as the problematic mesh: https://wustl.box.com/shared/static/tiw3hrx8krdkq1pg7oniosra7ruo2pwg.zip

---

This example is really helpful.

However, I cannot reproduce the issue on my installation using the latest master branch version.

Having a closer look at your files, it seems that some of the output files are corrupted. Coordinates of one node are incorrect (leading to the oddly placed node in the heart mesh) and a few nodes are missing (leading to the ill-defined tetrahedra due to an index shift).

Can you provide more info on your execution environment?
- openCARP version used
- launched serially or in parallel (mpirun)
- operating system

---

When simID was set to a child directory, as in the sample setup, I too did not see any issues.

Upon further investigation I was able to reproduce the issue in the sample setup by modifying simID to the .par file's current directory or the parent directory, e.g. "." and ".."

-Edit: Also would like to add that if reading the initial mesh from a parent directory, this also caused the same issue. Thus it seems the file corruption is caused by read/write operations of meshes to the current and parent directory.

- openCARP version used: v14.0 (hash a92e564a422c7ccf2ac1e84bc5a8267b39307bf9)
- launched serially or in parallel (mpirun): parallel using mpiexec
- operating system: Rocky Linux Green Obsidian

---

I changed the simID in your example from "./output"
to both "abc" and "../abc". Is this what causes incorrect outputs for you?
Both runs lead to correct output meshes on my machine, both with and without mpiexec.

---

Not exactly. What is causing issues is when I set simID to the current directory or the parent directory. For example, since the file I uploaded is called for_QA:

simID = ../for_QA
simID = .
simID = ..

All of these options will cause errors on my end.

---

All of these work for me as well even though the first two aren't good practice because your parameters.par file gets overwritten

---

Ok, thank you for checking on your end. I have had similar corruption issues happen to my .igb outputs because of a slow interconnect in the server, so at this point I am inclined to think there is an intrinsic problem with my server setup. Thanks again.