Validate drug-block channel labelling upfront instead of deep in the concentration loop

[Copilot]

Requesting a block on a channel not labelled in the model (e.g. --pic50-nal on a model without membrane_persistent_sodium_current_conductance) only threw once the simulation reached a non-zero concentration, since the check lived in ApplyDrugBlock and only fired when conductance_factor < 1. At conc=0, conductance_factor is exactly 1, so the run appeared to succeed for the control concentration and only failed later — making it look like the error was tied to a specific concentration's log file, when in fact chaste_errors_<rank>.txt is named by process rank, not concentration.

Fix

• Moved the labelling validation into ReadInIC50HillAndSaturation, firing as soon as a block is requested via --ic50-X/--pic50-X for a channel the model doesn't expose (respecting the existing ParameterWrapper Ito fallback rename).
• The exception now throws at setup time, before the concentration loop starts, with the same message as before.

Example

--model 1 --pic50-nal 1 --hill-nal 1 --saturation-nal 0 --plasma-conc-high 100 --plasma-conc-low 0 --plasma-conc-count 4

now fails immediately with ... does not have the current "membrane_persistent_sodium_current_conductance" labelled, but you have requested a block on this channel. instead of running through conc=0 first.

Tests

• Added a regression test in test/TestApPredict.hpp reproducing the issue's CLI arguments and asserting the exception is raised.

• Fixes <model> does not have the current "<conductance>" labelled, but you have requested a block on this channel #3

[mirams]

@copilot that might solve one problem, but do you know why the error was being written to the previous concentration error log file instead of the one of interest?

[Copilot]

@copilot that might solve one problem, but do you know why the error was being written to the previous concentration error log file instead of the one of interest?

Yes — it's not tied to concentration at all. chaste_errors_<N>.txt is named purely by MPI rank (PetscTools::GetMyRank()), not by concentration: see ExecutableSupport::PrintError in Chaste core (global/src/ExecutableSupport.cpp), which does OpenOutputFile("chaste_errors_", PetscTools::GetMyRank(), ".txt", std::ios::out | std::ios::app). Since ApPredict runs the whole concentration loop inside a single try/catch in main() (apps/src/ApPredict.cpp), and SetOutputDirectory/rank are fixed for the whole process, there is only ever one chaste_errors_0.txt for a serial run — every exception raised anywhere during that run (whichever concentration triggers it) gets appended to that same file. So "conc 0.001" was never going to get its own error file; the "0" in the filename is the process rank, not the concentration index. That's a naming/design characteristic of Chaste's top-level error reporting rather than a bug we can fix within ApPredict's concentration loop.

[mirams]

@copilot if the check is now done earlier, can it be removed from the loop over concentration code?