Thank you for the reference, Ted. I hadn't realized that their fitting setup would also be available on ModelDB. (In case anyone else might be looking for examples of MRF setup, its in the model's cell2 folder. Despite the readme file, it took me a moment to realize.)
It was definitely worth the look. For example, I hadn't realized that one generator can encompass multiple fit variables.
However, I'm still not sure about the best way to handle multiple experimental configurations with their own MRF generators. In my case, the configurations differ primarily in the presence, absence, or type of "instrumentation" (i.e., SEClamp or IClamp) at recording sites. The mitral cell model generators only appear to differ in initial conditions (v_init, e_pas) and the stimulus, and those are updated before each run while other model specifications are always constant (or perhaps I've missed something there).
To fit parameters involved in multiple configurations, it still seems one either needs to A) make duplicates of the cell with different instrumentation or B) use a 'Protocol Statement' to change the configuration. I'm leaning towards (A) right now, though I still have the concerns I mentioned before. Thinking about it a little more, (B) seems complicated by the fact that the 'Protocol Statement' would actually change the nature of the fit variables, perhaps in a way that would cause issues. For example, I'm not sure what would happen if the MRF was made to fit the voltage of an IClamp that is deleted and later reinstantiated.
On the more practical side of things, my approach to (A) has been to make two separate instances (copies/clones) of the cell and then instrument them differently, e.g., one copy's topology/morphology is specified as:
Code: Select all
create soma0
soma0 {
pt3dclear()
pt3dadd(0,0,0,1)
pt3dadd(1,1,1,3)
//and so on...
}
create axon0
axon0 {
pt3dclear()
pt3dadd(0,0,0,0.5)
pt3dadd(1,1,1,1)
//and so on...
}
connect axon0(0), soma0(1)
define_shape()
A second instance's morphology/topology is specified as:
Code: Select all
create soma1
soma1 {
pt3dclear()
pt3dadd(0,0,0,1)
pt3dadd(1,1,1,3)
//and so on...
}
create axon1
axon1 {
pt3dclear()
pt3dadd(0,0,0,0.5)
pt3dadd(1,1,1,1)
//and so on...
}
connect axon1(0), soma1(1)
define_shape()
Is there a way that I could better handle such duplicate instances? For creating them, I suppose I could make a list that holds the original set of sections (or perhaps it would have to be SectionRef objects), then write a procedure that iterates through the list, runs n3d(), x3d(), etc. and then runs the corresponding code to create the same sections under a different name.
The SectionRef class looks useful in this regard, but I was hoping for it to contain a duplicate() procedure. I guess what I'm really looking for is a CellRef class (that also has a duplicate procedure).