SCIRun User Mailing List

Text archives Help

Re: [SCIRUN-USERS] Forward ECG Problem

Chronological Thread 
  • From: Matthias Lange <>
  • To: Brett Burton <>
  • Cc: Alejandro Frangi <>,
  • Subject: Re: [SCIRUN-USERS] Forward ECG Problem
  • Date: Sat, 2 Apr 2016 22:18:51 +0100

Hi Brett
Thanks for your explanation, your solution worked for me. I didn't realised, that the segmentation was used as a mesh, or that a field is a mesh.


On 31 March 2016 at 23:06, Brett Burton <> wrote:

It wouldn't make sense for you to convert your mesh into a segmentation as long as your mesh is label mapped.  In the example network, the segmentation is essentially being used as a mesh anyway, so I'll see what I can do to explain how to alter the network so that you can incorporate your mesh file into it (assuming you are using the forward_problem network in the potential-based-fem directory of the toolkit).  Because this is going to the scirun user's list as well, I'm making this answer very descriptive (perhaps too descriptive).

In the network, the left most modules are:

1) ReadField -> 2) CreateLatVol
|-> 3) MapFieldDataOntoElements -> 4) ClipFieldByFunction -> 5) ClipFieldByFunction
      |-> 6) GetDomainBoundary

Here's what those fields are doing:
1) ReadField Reads in the segmentation
2) CreateLatVol Creates a volume that is 100x100x60 that will be used to reduce the total volume of the original nrrd (492x306x127)
3) MapFieldDataOntoElements Maps the original segmentation labels onto the lower resolution volume (this is a trick to reduce resolution of the original file so that it is manageable on smaller computers)
4) ClipFieldByFunction Clips the air label away from the rest of the torso
5) ClipFieldByFunction Clips the heart label out of the torso - so all you are left with is the torso (and all of its labels) with a hole where the heart used to be.  Technically, the two ClipFieldByFunction modules could be combined.
6) GetDomainBoundary Extracts the surface of the heart geometry (this will act as your epicardial potential source)

If you already have a labeled mesh, you could use a similar structure to pull the same information from your mesh, like this:

a) ReadField -> b) ClipFieldByFunction
|-> c) ClipFieldByFunction -> d) GetFieldBoundary

a) ReadField Read in your mesh
b) ClipFieldByFunction Remove the heart from your mesh (air too if you have it) by using, in the UI: DATA != #; // (label value of the heart)
b) ClipFieldByFunction Clip the heart out of your mesh to use as a source.  This time use DATA == #; // (label value of the heart)
d) GetFieldBoundary Extract the epicardial surface…you will be mapping your epicardial recordings onto this mesh (this replaces the GetDomainBoundary module from the example net)

Let me know if you still need an example network.

Brett Burton

PhD Candidate in Bioengineering | University of Utah

On Mar 31, 2016, at 7:15 AM, Liz Jurrus <> wrote:

Forwarding to the users list...  - liz

-------- Original Message --------
Subject: Re: Forward ECG Problem
Date: Wed, 30 Mar 2016 18:55:56 +0100
From: Matthias Lange <>
To: Dana Brooks <>
CC: Rob MacLeod <>, "Alexjandro (Alex) Frangi" <>

Hi Dana, Hi Rob 


Thanks for checking. Currently, I am working on using SCIRun to solve the forward ECG problem. That way I might be able to understand whether the problem is with the activation pattern or with my numerical solver of the forward ECG problem. 

However, the provided sample net needs a segmentations for the torso. I struggle to generate this, as I work with meshes. If you have a standard way of performing the conversion from mesh to segmentation, it would be helpful. Equal helpful would be if there is a sample net which uses a surface or volume mesh as input. 


Another question: Does SCIRun support the export of the standard ECG leads? This would be good for comparison. 




On 29 March 2016 at 18:39, Dana Brooks <> wrote:
Matthias hi,

just checking in to see where you stand with all this and if we can help in any way at this point ?



On 3/17/16 4:51 AM, Matthias Lange wrote:

Dear Rob, Dear Dana
I like to thank you for fast answers! Particular for mentioning the IBBM workshop, for which I handed in an application on Tuesday. >From both of your emails I noticed, that I haven't gave you information on my background. I studied physics with a focus on general relativity. From there I moved to my PhD, which started in 2012. The PhD is about the impact of the fast conduction system of the human heart, where I focus on the largely unexplored false tendon. I started with simulation based on the Eikonal equation and then developed a mono-domain solve for the Purkinje system. The implementation used the LifeV framework which also provides the mono-domain and bi-domain formulation for the myocardium. Furthermore, I made an effort to move the solver of the electrophysiology problem in the Purkinje to the GPU. My latest work is to implement the forward ECG solver. So far I haven't used SCIRun. This is because I haven't spend the time to understand how the GUI works. I hopeful I am lucky enough to be awarded with the IBBM fellowship, and then get a possibility to learn it. I know, that SCIRun is in theory able solve the forward ECG problem for a given transmembrane potential on the epicardium. However, I haven't figured out how to use a customised heart, which necessary because a statistical atlas is used to generate realistic heart shapes. Subsequently, I like to solve the electrophysiology problem and the forward ECG. This means the torso will need to be modified for each heart. ECGSim looks like a very interesting tool, which I didn't know about. Currently, I am going over the underlying publication, to understand the generation of the source potential. This seems to be of interest, as it builds a positive potential. So far I haven't understood where it comes from. Again, I like to thanks' for your time and effort. Best Matthias

On 14 March 2016 at 23:10, Rob MacLeod <> wrote:
Hi Matthias,

Sorry, I keep starting this email and trying to find ways to keep it short, then get distracted, then come back to it, and now I really have to attend to some other deadlines…  So here is a start and I will try to iterate soon.  
What I really think you should do is submit a fellowship application for our summer course.  The deadline in tomorrow and the fellowship will cover most of your expenses:

I am not being facetious as this course really is good and provides answers to a lot of this background material and to the use of all our SCI/CIBC/MRL software.  It is also a great time!   You can even see a video about it

The short answer to your specific question is that one must picture the activation in the heart as a wave front with polarized tissue in front and depolarized behind.  Under those conditions, intracellular current flows in one direction, extracellular in the opposite, as you note.  But one model at the tissue level is a dipole surface with sources and sinks split across the wavefront.  The size of the source is a function of the current or dipole moment of this source, i.e., the potential gradient that appears in the equation you included.  From here, the path diverges depending on which sort of source formulation you want to pick, as simple as a fixed dipole that change direction and as complex and a full bidomain.  

One key that I cannot find in the description is what sort of sequence of activation you have (or came out of the simulations).  This is key and without it, you will generate strange ECGs.  

Another approach to test your code is to pick a static point in time, assign potentials in the heart to what we know to be at least approximately right, and then see how your potentials distribute on the torso surface.  There are lots of textbook examples of the sequence of activation that can guide you in setting the transmembrane potentials in different regions of the heart. 

I need to wrap up now but we can certainly iterate more.  I cannot tell where to jump into the derivation as I also cannot tell the extent of your previous training or background in electrophysiology and bioelectricity.  

Best (for now),

On Mar 14, 2016, at 08:08 , Dana Brooks <brooks@ECE.NEU.EDU> wrote:

Matthias hi,

I am going to bring Rob MacLeod in on this discussion. Although I might be able to get some of this figured out, I suspect Rob will do so with much more accuracy and much more rapidity too !

BTW Alex mentioned that you are using SCIRun and some of the figures looked familiar --- can you tell us a bit about if/ / how you are using SCIRUn ?

and have you looked at ECGSIM ? Although it uses a surface transmembrane potential source model rather than a bidomain source, it is a very useful standard to compare TMPs and surface potentials against and allows very nice examination of details of how a forward model is working.

Rob hi,

please see below.  Looking forward to your explanation :-)



-------- Original Message --------
Subject: Forward ECG Problem
Date: Mon, 14 Mar 2016 09:42:42 +0000
From: Matthias Lange <>
CC: Alejandro Frangi <>, Toni Lassila <>

Dear Prof. Brooks

I am a PhD student of Prof Alejandro Frangi working on cardiac simulations. Alejandro told me that you kindly agreed to have a look at a problem I have with the forward ECG.

We are developing a solver for the uncoupled bi-domain equations in three dimensions. The problem is that we observe an inverted ECG in our simulations. Furthermore, I do not understand why the real ECG has the opposite orientation.

To generate realistic orientated ECGs, the left leg lead needs to be positive against the right arm lead. In simulations reported in the literature this happens because of two charge accumulations. The left side of the body becomes positive compared to the resting state, while the right hand side becomes negative compared to the resting state. To generate this surface charge distribution the extracellular potential at the heart apex needs to turn positive, while at the base it should become negative. All this would need to happen during depolarisation.

At this point I get confused. My understanding is that the action potential arises because positive charge from the extracellular space is entering the intracellular space, i.e. Na+. This should result in a lower extracellular potential compared against the resting potential. This contradicts the assumption of a positive charged apex as stated in the first paragraph.

In our simulation, we observe a negative extracellular potential during depolarisation. Solving the forward problem with a negative extracellular potential at the heart apex results in a negative body surface potential on the left side of the body. This potential distribution is in line with the ECG we observed. However, it is inverted with respect to a real ECG and what others report for their simulations.

Obviously, some of the assumptions or conclusions have to be invalid. To me it is not clear where I made the mistake.

Attached is a document describing the mathematical formulation we used, including a few images of the heart activation and the torso potentials. If you need the 3D simulation results let me know and I will share them with you in Google Drive.

Any thought are highly appreciated, and I would like to thank you very much for your effort.

Best wishes,



SCIRun users mailing list:
To unsubscribe, email with the "unsubscribe scirun-users" in the message body.

Archive powered by MHonArc 2.6.18.

Top of page