Fixing domain-specific conductances for EP

[javijv4]

Current situation

Resolves #504

Code of Conduct & Contributing Guidelines

• I agree to follow the Code of Conduct and Contributing Guidelines.

[codecov]

Codecov Report

❌ Patch coverage is 52.08333% with 23 lines in your changes missing coverage. Please review.
✅ Project coverage is 67.72%. Comparing base (869da67) to head (06a3f33).

Files with missing lines	Patch %	Lines
Code/Source/solver/cep_ion.cpp	32.35%	23 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #506      +/-   ##
==========================================
+ Coverage   67.70%   67.72%   +0.01%     
==========================================
  Files         168      168              
  Lines       32752    32752              
  Branches     5750     5748       -2     
==========================================
+ Hits        22176    22182       +6     
+ Misses      10439    10433       -6     
  Partials      137      137              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[kko27]

Maybe this is overkill, but is it possible to use test different ionic models applied to various domains? We may in the future need to test this because there are other cells (such as conduction cells) that deviate from ventricular cardiomyocyte EP.

[javijv4]

I think that's a good idea, but there are some issues with doing that in a slab. I tried it with TTP and AP (the left domain is AP), and since they have different resting potentials, the AP domain excites the TTP domain. The good thing is that this proves it is possible to have two different ionic models (this was possible before too).

So, I do not think a slab with multiple ionic models makes sense. I could create a test with 3D-1D coupling to replicate the case where we will use two ionic models, but we can also add such a test once we have a Purkinje-specific ionic model, which is when we will actually be using two ionic models.

What do you think? I can create a 3D-1D test now and update it when we implement the Purkinje-specific ionic model, or wait to add it when we create the Purkinje-specific ionic model. Either one is good with me.

[kko27]

Wow. I realized now that there were a lot of places where the cep_mod was incorrectly used. I think this all looks correct to me...

[ktbolt]

@javijv4 Be sure to update the Issue #504 with a brief description about how you fixed the Issue.

[ktbolt]

@javijv4 All of these if-statements can be replaced with something like

std::map<Parameter<double>*,double*> ttp_params{
   {&domain_params->G_Na,&lDmn.cep.ttp.G_Na},
   {&domain_params->G_Kr,&lDmn.cep.ttp.G_Kr}
 };

  for (auto& [ param, value] : ttp_params) {
    if (param->defined()) {
      *value = param->value();
    }
  }

[ktbolt]

@javijv4 I don't like the look of this

lDmn.cep.ttp.G_to[lDmn.cep.imyo - 1]

cepModelType::imyo should not even be an int, should be an enum.

[javijv4]

@ktbolt I also don't like it. I believe this statement lDmn.cep.ttp.G_to[lDmn.cep.imyo - 1] is there to handle within the code different myocardial zones. I think the user should define different domains and assign parameters to each domain in the .xml file, such that there is a single G_Ks, G_to for each domain, same as with G_Na, G_Kr and G_Cal.

Can we create a separate issue for this? I think CepModTtp shouldn't use imyo at all, and the user should create separate domains to assign parameters to different regions, with some useful default values defined in the code (as in this issue here). But this is more of a TTP issue, different from the domain-specific values.

@kko27, does modifying TTP to be agnostic of imyo make sense to you? (If we can correctly assign conductances based on domains).

[kko27]

@javijv4 and @ktbolt. This was my original plan in my issue but I was thinking for backward compatibility, it made sense to keep these hard-coded values. But it works for me to remove the initial conditions entirely from the codebase