Hi,
Curious about how d_lamda is implemented in Cellbuilder. Is the Ra used to compute lamda_f taken from what the user inputs in CellBuilder/biophysics only? Say the user is fitting for Ra at a later stage. Is that Ra taken into account?
d_lambda optimization
-
ted
- Site Admin
- Posts: 6299
- Joined: Wed May 18, 2005 4:50 pm
- Location: Yale University School of Medicine
- Contact:
Re: d_lambda optimization
Ra is specified via statements in hoc or Python, which are procedural programming languages. This means that the value of any variable foo at any time is the value that was specified in the most recently executed assignment statement
foo = whatever
Spatial discretization with the d_lambda rule, however, occurs only if parameter changes are made inside the CellBuilder itself. If you plan to change biophysical parameters (cm and Ra) that may affect the fineness of spatial discretization that is necessary for good accuracy in space, it is probably a good idea to start by making nseg appropriate for the worst case. In the CellBuilder, set Ra and cm to the largest values you plan to use, and use the d_lambda rule for spatial discretization. If you intend to change any section's diameter or length, you should also set these parameters to their worst-case values (smallest diameter, longest length). This will force nseg in each section to be large enough that spatial accuracy will not have to be adjusted.
Alternatively, you could apply the d_lambda rule to each section after making your parameter changes. To see how, make a toy model cell (ball and stick will do), then export that to a hoc file (Management page, click on Export, then click on Export to file) and look for proc geom_nseg(). Just put a copy that procedure in your own code, and call it after any parameter change. The disadvantage of this approach is that changing nseg will change the locations of internal nodes (segment centers), and this will force relocation of any point process that is attached to an internal node. If point processes are attached to internal nodes, it is best to start with the finest spatial grid you are going to need, and leave nseg unchanged after that.
Here is a cautionary note:
When a CellBuilder is in "Continuous Create" mode (i.e. when a check mark appers in its Continuous Create box), if you use the CellBuilder's GUI to change a parameter of the model cell, that change will immediately take effect. This feature is very helpful for exploratory model development, but you must be careful to avoid it if you want to use your own hoc statements to change model parameters. Otherwise, you could do something with the CellBuilder's GUI that overrides a change that was made by your own hoc code. To prevent this from happening, just make sure that, after your code reads or loads a ses file that recreates a CellBuilder with Continuous Create on, you turn that CellBuilder's Continuous Create off. This is easy to do with an assignment statement, as in this example:
foo = whatever
Spatial discretization with the d_lambda rule, however, occurs only if parameter changes are made inside the CellBuilder itself. If you plan to change biophysical parameters (cm and Ra) that may affect the fineness of spatial discretization that is necessary for good accuracy in space, it is probably a good idea to start by making nseg appropriate for the worst case. In the CellBuilder, set Ra and cm to the largest values you plan to use, and use the d_lambda rule for spatial discretization. If you intend to change any section's diameter or length, you should also set these parameters to their worst-case values (smallest diameter, longest length). This will force nseg in each section to be large enough that spatial accuracy will not have to be adjusted.
Alternatively, you could apply the d_lambda rule to each section after making your parameter changes. To see how, make a toy model cell (ball and stick will do), then export that to a hoc file (Management page, click on Export, then click on Export to file) and look for proc geom_nseg(). Just put a copy that procedure in your own code, and call it after any parameter change. The disadvantage of this approach is that changing nseg will change the locations of internal nodes (segment centers), and this will force relocation of any point process that is attached to an internal node. If point processes are attached to internal nodes, it is best to start with the finest spatial grid you are going to need, and leave nseg unchanged after that.
Here is a cautionary note:
When a CellBuilder is in "Continuous Create" mode (i.e. when a check mark appers in its Continuous Create box), if you use the CellBuilder's GUI to change a parameter of the model cell, that change will immediately take effect. This feature is very helpful for exploratory model development, but you must be careful to avoid it if you want to use your own hoc statements to change model parameters. Otherwise, you could do something with the CellBuilder's GUI that overrides a change that was made by your own hoc code. To prevent this from happening, just make sure that, after your code reads or loads a ses file that recreates a CellBuilder with Continuous Create on, you turn that CellBuilder's Continuous Create off. This is easy to do with an assignment statement, as in this example:
Code: Select all
// assumes that there is no CellBuilder at this point
load_file("cell.ses") // cell.ses recreates a CellBuilder that has Continuous Create on
CellBuild[0].continuous=0 // turn off its Continuous CreateRe: d_lambda optimization
Hi Ted,
Thank you for the wonderful, complete answer. I am especially grateful for your suggestion to use worst-case (largest) values for Ra and Cm, if pursuing option 1.
-Charles
Thank you for the wonderful, complete answer. I am especially grateful for your suggestion to use worst-case (largest) values for Ra and Cm, if pursuing option 1.
-Charles