Is this simply a warning or I did something wrong?

[eacheon]

I got the following info when I was running my hoc script, wondering is this only a warning or is signaling something I need to correct: NEURON 5.8

Code: Select all

The sectionstack index should be 0 but it is 1
/home/eacheon/nrn58/nrn/i686/bin/nrniv: prior to version 5.3 the section stack would not have been properly popped
and the currently accessed section would have been  dend[32]
 in test_place_syn.hoc near line 78
 section_init(sectionset)
                                 ^

Thanks!

[ted]

What source code provoked this message?

[eacheon]

What source code provoked this message?

kind of complicated. Let me trim it to the smallest part to reproduce the problem. I read this message in the ChangeLog of NEURON, so I had hoped this might be a problem addressed already.

Code: Select all

Fri May 17 20:56:42 2002  hines  <hines@miranda>

	...

	* nrn5/src/ivoc/ocjump.cpp, nrn5/src/nrnoc/cabcode.c, nrn5/src/nrnoc/point.c, nrn5/src/nrnoc/seclist.c, nrn5/src/oc/code.c:
	The very old bug in not popping the section stack when a continue, break,	or return occurred in a section statement is fixed.
	The section stack pointer was converted to an integer to make it
	easier to pop the section stack back to a known point when hoc_returning is non-zero. At the moment the following warning is printed if this feature takes effect:
	The sectionstack index should be 0 but it is 1
	nrniv: prior to version 5.3 the section stack would not have been
	properly popped and the currently accessed section would
	have been  b in secstack.hoc

	THis feature is necessarily turned off between a
	push_section()...pop_section() fragment.

Yes I confirm that in my code there is continue, break in the section statement. In the last loop the currently accessed section is the one the message says to be "would have been" (dend[32]).

After the execution of my script, psection() prints info of soma. Is this the supposed behavior from the above notes? there may not be a problem here, am I understanding it right?

It is kind of complicate code, I may need some time to reduce it.

[ted]

The message is not fatal in the sense of "there is something wrong that may crash the
program." It is potentially much worse, in the sense of "the program may execute without
apparent error, but the user may easily misinterpret the outcome of the simulation because
of confusion about the identity of the currently accessed section." Isolating the cause and
eliminating it now--before you produce a large body of misinterpreted simulation results--
would be time well spent.

[eacheon]

Thanks, the following code replicate the warning message:

Code: Select all

/* 
   An example trying to replicate the error. 
*/


create soma, dend[1] 
access soma
connect dend[0](0), 1
dend[0] {L=100}

//---------------------------------------------------------------------
// SectionPart, representing part of a section.
begintemplate SectionPart
public secref, start, end 
objref secref

proc init() {
  secref = new SectionRef() 
  start = $1
  end = $2
}
endtemplate SectionPart

//---------------------------------------------------------------------
// SectionPartList
begintemplate SectionPartList
public list, all, append
objref list

proc init() {
  list = $o1 
}

iterator all() {localobj foo 
  for i=0, list.count-1 {
    foo = list.object(i)
    $&1 = foo.start
    $&2 = foo.end
    foo.secref.sec { 
      iterator_statement
    }  
  //  foo.secref.sec iterator_statement produces a segment error
  }
}
endtemplate SectionPartList


//-------------------------------------------------------------------

// initiate a SectionList 
objref seclist
seclist = new SectionList()
dend[0] seclist.append()

// a list of the SectionPart objects.
objref spart, spl, splist
dend[0] spart = new SectionPart(0.1, 0.5)
spl = new List()
spl.append(spart)
splist = new SectionPartList(spl)

print "section part list built."
print "splist is ",splist

// so hopefully this iterates through all the SectionParts
start=0
end=0
for splist.all(&start, &end) {
    psection()
    print "L:", L, "  [", start, ", ",  end, "]"
    break // but when you break from this loop, NEURON throw out a warning.
}    

print "then after the warning, the interpreter continues from here"

[Raj]

You can reorganize your iterator so that you can bring the break statement outside of the section access block:

Code: Select all

iterator all() {localobj foo
  for i=0, list.count-1 {
    foo = list.object(i)
    $&1 = foo.start
    $&2 = foo.end
    $o3 = foo.secref
	
	iterator_statement
    
  //  foo.secref.sec iterator_statement produces a segment error
  }
}

and now

Code: Select all

start=0
end=0
objref mySecRef
for splist.all(&start, &end,mySecRef) {
    mySecRef.sec {
		psection()
	    print "L:", L, "  [", start, ", ",  end, "]"
    }
    break 
}   

iterates through all the SectionParts, still allowing a break statement.

Although this solution works in your example I am wondering whether it is the right solution. Passing break statements to an iterator does not look like good coding style to me, so you might want to restructure the iterator further so that it can meet your needs in another way.

[ted]

Raj makes a good point. It's hard to be more specific without knowing more about your
grand plan (which may be too proprietary for public discussion), but I wonder if it is possible
to recast your strategy in a way that doesn't require an iterator at all.

[eacheon]

Raj makes a good point. It's hard to be more specific without knowing more about your
grand plan (which may be too proprietary for public discussion), but I wonder if it is possible
to recast your strategy in a way that doesn't require an iterator at all.

The idea is simple. I need to iterate through a list of objects each one of which represents part of a section (so I need to acess the section, a start point x and an end point y in a loop.)

There's code which I took doing the job of iterating though a SectionList via "forsec" loop, which is fine when breaked from inside (in the means that it works and does not produce the warning message).

Code: Select all

forsec seclist {
     ...
     break //sometimes
}

I would like something similiar:

Code: Select all

forsecpart secpartlist {
     ...
     (start, end, and current section is getting iterated on here)
     break //sometimes
}

I thought the iterator was the way to go.
Still have not tried Raj's solution, let me try...

[eacheon]

You can reorganize your iterator so that you can bring the break statement outside of the section access block:

...

iterates through all the SectionParts, still allowing a break statement.

Although this solution works in your example I am wondering whether it is the right solution. Passing break statements to an iterator does not look like good coding style to me, so you might want to restructure the iterator further so that it can meet your needs in another way.

Thanks Raj, this seems to work right now. My problem is some legacy code I am trying to use has "break" in forsec loop which works fine, while I was trying to do something similiar to "forsec" but to iterate through a SectionPartList. Could u give some ideas on better coding style in this case?

[Raj]

It's hard to be more specific without knowing more about your
grand plan (which may be too proprietary for public discussion), but I wonder if it is possible
to recast your strategy in a way that doesn't require an iterator at all.

Just quoting Ted to point out the problem with answering this question.

I think adding an iterator to an object which in essence is a list is a good technique. If, however, you find yourself selecting subsets of this list, which is effectively what you are doing when using a break statement, then the list is probably combining elements which do not belong together from the point of view of program structure. So the first idea would be to split the list into smaller lists in which you combine elements that you want to treat the same way.

To say anything more usefull then this generality I would need to know the nature of the condition on which you issue the break statement.

[eacheon]

It's hard to be more specific without knowing more about your
grand plan (which may be too proprietary for public discussion), but I wonder if it is possible
to recast your strategy in a way that doesn't require an iterator at all.

Just quoting Ted to point out the problem with answering this question.

I think adding an iterator to an object which in essence is a list is a good technique. If, however, you find yourself selecting subsets of this list, which is effectively what you are doing when using a break statement, then the list is probably combining elements which do not belong together from the point of view of program structure. So the first idea would be to split the list into smaller lists in which you combine elements that you want to treat the same way.

To say anything more usefull then this generality I would need to know the nature of the condition on which you issue the break statement.

Hah, the part you are asking is actually from some legacy code (which uses forsec to iterate through all the sections). In my understanding it has sort of complicated loops which build different synapses on a set of sections. These synapses have different types (point processes) and fall into different groups which serving different sequence of presynaptic firing,
so you can imagine there's two criterions to iterate through: all the sections and all the groups. So I guess that's the reason some judgment is made and breaks are issued inside a forsec loop, which works fine.

Do not know if this discription is enough for getting some rough idea about the problem, but that's what I got from reading through the code. I can find out some breaks are issued for speed reason, some I still have not quite understood, but they deals with different issues and cases where the author feels no necessary to continue this loop, and since neuron doesn't complain when break from a forsec loop, it has been written that way.

I agree maybe one can avoid iterator here.

[Raj]

If break is used to save time during construction of the model it is probably the wrong kind of optimization. If it is used to optimize the extraction of information during program execution, you might actually be able to speed up further by splitting the list the right way.

At least make sure you know what these complicated loops are doing.

Success!