Menu
▾
▴
moose-devel
|
From: Saeed S. <sd....@gm...> - 2014-04-29 15:34:45
|
Hi, At async13 branch, when it tries to use connect method, the below error throws away: 0: Shell::doAddMsg: Error: Failed to find field spike on src: cell_0 It would be my please if you have a look at this. Bests, Saeed |
|
From: Saeed <sa...@gn...> - 2014-04-29 17:58:37
|
Sure, Sorry for the lack of information.
As I found it happens in many of Demo files, for example at "async13/Demos/snippets/testHsolve.py" the below error produces:
=====================================
on node 0, numNodes = 1, numCores = 12
Info: Time to define moose classes:0
Info: Time to initialize module:0.05
Created 306 path=/n numData=1 isGlobal=0 baseType=Neutral
Created 307 path=/n/compt numData=1 isGlobal=0 baseType=SymCompartment
Created 308 path=/n/compt/Na numData=1 isGlobal=0 baseType=HHChannel
Created 312 path=/n/compt/K numData=1 isGlobal=0 baseType=HHChannel
Created 316 path=/n/compt/synInput numData=1 isGlobal=0 baseType=SpikeGen
Created 317 path=/n[0]/shaft0 numData=1 isGlobal=0 baseType=SymCompartment
Created 318 path=/n[0]/head0 numData=1 isGlobal=0 baseType=SymCompartment
Created 319 path=/n[0]/head0[0]/gluR numData=1 isGlobal=0 baseType=SynChan
Created 321 path=/n[0]/head0[0]/ca numData=1 isGlobal=0 baseType=CaConc
0: Shell::doAddMsg: Error: Failed to find field event on src: synInput
Traceback (most recent call last):
File "testHsolve.py", line 297, in <module>
main()
File "testHsolve.py", line 294, in main
test_elec_alone()
File "testHsolve.py", line 265, in test_elec_alone
make_spiny_compt()
File "testHsolve.py", line 243, in make_spiny_compt
moose.connect( synInput, 'event', syn, 'addSpike', 'Single' )
NameError: check field names and type compatibility.
======================================
It seems that the finfoMap_ array at Cinfo.cpp:214 does not contains all object names.
>Upi
> Dear Saeed,
> Please give script snippet where this happens. Also you might wish
> to look in Demos/snippets for examples of the correct use of the function.
> Best,
> Upi
> On Tuesday 29 April 2014 09:04 PM, Saeed Shariati wrote:
>> Hi,
>>
>> At async13 branch, when it tries to use connect method, the below error
>> throws away:
>>
>> 0: Shell::doAddMsg: Error: Failed to find field spike on src: cell_0
>>
>> It would be my please if you have a look at this.
>>
>> Bests,
>> Saeed
>> ------------------------------------------------------------------------------
>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>> Instantly run your Selenium tests across 300+ browser/OS combos. Get
>> unparalleled scalability from the best Selenium testing platform available.
>> Simple to use. Nothing to install. Get started now for free."
>>http://p.sf.net/sfu/SauceLabs
>> _______________________________________________
>> moose-devel mailing list
>> moose-devel@...
>>https://lists.sourceforge.net/lists/listinfo/moose-devel
|
|
From: Dilawar S. <dil...@nc...> - 2014-04-29 18:03:50
|
Hi Saeed,
We are in process of integrating 'hsolve' into async13 branch. Only today, I
got some sanity check of hsolve working. I am not sure how long it will take
to get hsolve properly integrated with python.
For time being -- if you want to use async13 branch -- you can change the
solver to 'ee' from 'hsolve'.
I'll let you know as soon as hsolve is ready.
Dilawar
On Tue, Apr 29, 2014 at 02:58:28PM -0300, Saeed wrote:
>Sure, Sorry for the lack of information.
>As I found it happens in many of Demo files, for example at "async13/Demos/snippets/testHsolve.py" the below error produces:
>
>=====================================
>on node 0, numNodes = 1, numCores = 12
>Info: Time to define moose classes:0
>Info: Time to initialize module:0.05
>Created 306 path=/n numData=1 isGlobal=0 baseType=Neutral
>Created 307 path=/n/compt numData=1 isGlobal=0 baseType=SymCompartment
>Created 308 path=/n/compt/Na numData=1 isGlobal=0 baseType=HHChannel
>Created 312 path=/n/compt/K numData=1 isGlobal=0 baseType=HHChannel
>Created 316 path=/n/compt/synInput numData=1 isGlobal=0 baseType=SpikeGen
>Created 317 path=/n[0]/shaft0 numData=1 isGlobal=0 baseType=SymCompartment
>Created 318 path=/n[0]/head0 numData=1 isGlobal=0 baseType=SymCompartment
>Created 319 path=/n[0]/head0[0]/gluR numData=1 isGlobal=0 baseType=SynChan
>Created 321 path=/n[0]/head0[0]/ca numData=1 isGlobal=0 baseType=CaConc
>0: Shell::doAddMsg: Error: Failed to find field event on src: synInput
>Traceback (most recent call last):
> File "testHsolve.py", line 297, in <module>
> main()
> File "testHsolve.py", line 294, in main
> test_elec_alone()
> File "testHsolve.py", line 265, in test_elec_alone
> make_spiny_compt()
> File "testHsolve.py", line 243, in make_spiny_compt
> moose.connect( synInput, 'event', syn, 'addSpike', 'Single' )
>NameError: check field names and type compatibility.
>
>======================================
>
>It seems that the finfoMap_ array at Cinfo.cpp:214 does not contains all object names.
>
>
>
>>Upi
>> Dear Saeed,
>> Please give script snippet where this happens. Also you might wish
>> to look in Demos/snippets for examples of the correct use of the function.
>> Best,
>> Upi
>> On Tuesday 29 April 2014 09:04 PM, Saeed Shariati wrote:
>>> Hi,
>>>
>>> At async13 branch, when it tries to use connect method, the below error
>>> throws away:
>>>
>>> 0: Shell::doAddMsg: Error: Failed to find field spike on src: cell_0
>>>
>>> It would be my please if you have a look at this.
>>>
>>> Bests,
>>> Saeed
>>> ------------------------------------------------------------------------------
>>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>>> Instantly run your Selenium tests across 300+ browser/OS combos. Get
>>> unparalleled scalability from the best Selenium testing platform available.
>>> Simple to use. Nothing to install. Get started now for free."
>>>http://p.sf.net/sfu/SauceLabs
>>> _______________________________________________
>>> moose-devel mailing list
>>> moose-devel@...
>>>https://lists.sourceforge.net/lists/listinfo/moose-devel
>
>
>------------------------------------------------------------------------------
>"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>Instantly run your Selenium tests across 300+ browser/OS combos. Get
>unparalleled scalability from the best Selenium testing platform available.
>Simple to use. Nothing to install. Get started now for free."
>http://p.sf.net/sfu/SauceLabs
>_______________________________________________
>moose-devel mailing list
>moo...@li...
>https://lists.sourceforge.net/lists/listinfo/moose-devel
|
|
From: Dave B. <db...@Co...> - 2014-04-29 20:04:42
|
I will be very interested in trying out the MOOSE Python implemention of hsolved when it is fully ready. In GENESIS 2, hsolve performs both the functions of a Hines method compartmental solver, and of a Discrete Event Solver for the efficient delivery of spike messages. Ideally, these should be in separate solvers, as they are in GENESIS 3 (unfortunately still under development). How is this being handled in MOOSE? Can networks of hsolved cells in MOOSE benefit from equivalent optimizations in spike delivery that GENESIS hsolve gives? Or is a separate mechanism used for spike delivery? On Tue, 29 Apr 2014, Dilawar Singh wrote: > Hi Saeed, > > We are in process of integrating 'hsolve' into async13 branch. Only today, I > got some sanity check of hsolve working. I am not sure how long it will take > to get hsolve properly integrated with python. > > For time being -- if you want to use async13 branch -- you can change the > solver to 'ee' from 'hsolve'. > > I'll let you know as soon as hsolve is ready. > > Dilawar |
|
From: Jaeger, D. <dj...@em...> - 2014-04-29 20:24:04
|
Same interest here. -Dieter -----Original Message----- From: Dave Beeman [mailto:db...@Co...] Sent: Tuesday, April 29, 2014 4:05 PM To: Moose development issues Subject: Re: [moose-devel] Error in moose.connect method I will be very interested in trying out the MOOSE Python implemention of hsolved when it is fully ready. In GENESIS 2, hsolve performs both the functions of a Hines method compartmental solver, and of a Discrete Event Solver for the efficient delivery of spike messages. Ideally, these should be in separate solvers, as they are in GENESIS 3 (unfortunately still under development). How is this being handled in MOOSE? Can networks of hsolved cells in MOOSE benefit from equivalent optimizations in spike delivery that GENESIS hsolve gives? Or is a separate mechanism used for spike delivery? On Tue, 29 Apr 2014, Dilawar Singh wrote: > Hi Saeed, > > We are in process of integrating 'hsolve' into async13 branch. Only today, I > got some sanity check of hsolve working. I am not sure how long it will take > to get hsolve properly integrated with python. > > For time being -- if you want to use async13 branch -- you can change the > solver to 'ee' from 'hsolve'. > > I'll let you know as soon as hsolve is ready. > > Dilawar ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ moose-devel mailing list moo...@li... https://lists.sourceforge.net/lists/listinfo/moose-devel |
|
From: Saeed S. <sa...@gn...> - 2014-04-29 22:00:43
|
Dear Dave,
In my opinion, HSolve strategy in the Moose is different than
Genesis. It is more an integration algorithm than overall framework.
It applies to a part of the general simulation and communicate with
external objects. However, objects such as active and synaptic
channels are HSolvable, spike delivery serves outside of HSolve. The
good thing is that with this mechanism, it's possible to use HSolve
in a complex models that have non-HSolvabe objects.
Saeed
On 04/29/2014 05:04 PM, Dave Beeman wrote:
> I will be very interested in trying out the MOOSE Python implemention
> of hsolved when it is fully ready.
>
> In GENESIS 2, hsolve performs both the functions of a Hines method
> compartmental solver, and of a Discrete Event Solver for the efficient
> delivery of spike messages. Ideally, these should be in separate solvers,
> as they are in GENESIS 3 (unfortunately still under development).
>
> How is this being handled in MOOSE? Can networks of hsolved cells
> in MOOSE benefit from equivalent optimizations in spike delivery that
> GENESIS hsolve gives? Or is a separate mechanism used for spike delivery?
>
> On Tue, 29 Apr 2014, Dilawar Singh wrote:
>
>> Hi Saeed,
>>
>> We are in process of integrating 'hsolve' into async13 branch. Only today, I
>> got some sanity check of hsolve working. I am not sure how long it will take
>> to get hsolve properly integrated with python.
>>
>> For time being -- if you want to use async13 branch -- you can change the
>> solver to 'ee' from 'hsolve'.
>>
>> I'll let you know as soon as hsolve is ready.
>>
>> Dilawar
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> moose-devel mailing list
> moo...@li...
> https://lists.sourceforge.net/lists/listinfo/moose-devel
>
>
|
|
From: Saeed <sa...@gn...> - 2014-04-29 18:17:01
|
Hi Dilawar,
Thank you for importing hsolve. I thought it might be not related
to HSolve because it happened before defining HSovle and for example at
Hopfield I got the same error.
Thank you again. Therefore, I wont change anything now and will
wait for the code to be stable.
Saeed
On 29-04-2014 15:02, Dilawar Singh wrote:
> Hi Saeed,
>
> We are in process of integrating 'hsolve' into async13 branch. Only today, I
> got some sanity check of hsolve working. I am not sure how long it will take
> to get hsolve properly integrated with python.
>
> For time being -- if you want to use async13 branch -- you can change the
> solver to 'ee' from 'hsolve'.
>
> I'll let you know as soon as hsolve is ready.
>
> Dilawar
>
> On Tue, Apr 29, 2014 at 02:58:28PM -0300, Saeed wrote:
>> Sure, Sorry for the lack of information.
>> As I found it happens in many of Demo files, for example at "async13/Demos/snippets/testHsolve.py" the below error produces:
>>
>> =====================================
>> on node 0, numNodes = 1, numCores = 12
>> Info: Time to define moose classes:0
>> Info: Time to initialize module:0.05
>> Created 306 path=/n numData=1 isGlobal=0 baseType=Neutral
>> Created 307 path=/n/compt numData=1 isGlobal=0 baseType=SymCompartment
>> Created 308 path=/n/compt/Na numData=1 isGlobal=0 baseType=HHChannel
>> Created 312 path=/n/compt/K numData=1 isGlobal=0 baseType=HHChannel
>> Created 316 path=/n/compt/synInput numData=1 isGlobal=0 baseType=SpikeGen
>> Created 317 path=/n[0]/shaft0 numData=1 isGlobal=0 baseType=SymCompartment
>> Created 318 path=/n[0]/head0 numData=1 isGlobal=0 baseType=SymCompartment
>> Created 319 path=/n[0]/head0[0]/gluR numData=1 isGlobal=0 baseType=SynChan
>> Created 321 path=/n[0]/head0[0]/ca numData=1 isGlobal=0 baseType=CaConc
>> 0: Shell::doAddMsg: Error: Failed to find field event on src: synInput
>> Traceback (most recent call last):
>> File "testHsolve.py", line 297, in <module>
>> main()
>> File "testHsolve.py", line 294, in main
>> test_elec_alone()
>> File "testHsolve.py", line 265, in test_elec_alone
>> make_spiny_compt()
>> File "testHsolve.py", line 243, in make_spiny_compt
>> moose.connect( synInput, 'event', syn, 'addSpike', 'Single' )
>> NameError: check field names and type compatibility.
>>
>> ======================================
>>
>> It seems that the finfoMap_ array at Cinfo.cpp:214 does not contains all object names.
>>
>>
>>
>>> Upi
>>> Dear Saeed,
>>> Please give script snippet where this happens. Also you might wish
>>> to look in Demos/snippets for examples of the correct use of the function.
>>> Best,
>>> Upi
>>> On Tuesday 29 April 2014 09:04 PM, Saeed Shariati wrote:
>>>> Hi,
>>>>
>>>> At async13 branch, when it tries to use connect method, the below error
>>>> throws away:
>>>>
>>>> 0: Shell::doAddMsg: Error: Failed to find field spike on src: cell_0
>>>>
>>>> It would be my please if you have a look at this.
>>>>
>>>> Bests,
>>>> Saeed
>>>> ------------------------------------------------------------------------------
>>>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>>>> Instantly run your Selenium tests across 300+ browser/OS combos. Get
>>>> unparalleled scalability from the best Selenium testing platform available.
>>>> Simple to use. Nothing to install. Get started now for free."
>>>> http://p.sf.net/sfu/SauceLabs
>>>> _______________________________________________
>>>> moose-devel mailing list
>>>> moose-devel@...
>>>> https://lists.sourceforge.net/lists/listinfo/moose-devel
>>
>> ------------------------------------------------------------------------------
>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>> Instantly run your Selenium tests across 300+ browser/OS combos. Get
>> unparalleled scalability from the best Selenium testing platform available.
>> Simple to use. Nothing to install. Get started now for free."
>> http://p.sf.net/sfu/SauceLabs
>> _______________________________________________
>> moose-devel mailing list
>> moo...@li...
>> https://lists.sourceforge.net/lists/listinfo/moose-devel
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> moose-devel mailing list
> moo...@li...
> https://lists.sourceforge.net/lists/listinfo/moose-devel
>
>
|
|
From: Dilawar S. <dil...@gm...> - 2014-05-01 09:28:14
|
Hi Saeed,
Script testHsolve.py runs now. Checkout #5330.
Numpy vector will be printed on console. I am not sure about the correctness
of results. This revision (#5330) should be stable for building moose.
Dilawar
On Tue, Apr 29, 2014 at 03:16:52PM -0300, Saeed wrote:
>Hi Dilawar,
>
> Thank you for importing hsolve. I thought it might be not related
>to HSolve because it happened before defining HSovle and for example at
>Hopfield I got the same error.
> Thank you again. Therefore, I wont change anything now and will
>wait for the code to be stable.
>
>Saeed
>
>
>On 29-04-2014 15:02, Dilawar Singh wrote:
>> Hi Saeed,
>>
>> We are in process of integrating 'hsolve' into async13 branch. Only today, I
>> got some sanity check of hsolve working. I am not sure how long it will take
>> to get hsolve properly integrated with python.
>>
>> For time being -- if you want to use async13 branch -- you can change the
>> solver to 'ee' from 'hsolve'.
>>
>> I'll let you know as soon as hsolve is ready.
>>
>> Dilawar
>>
>> On Tue, Apr 29, 2014 at 02:58:28PM -0300, Saeed wrote:
>>> Sure, Sorry for the lack of information.
>>> As I found it happens in many of Demo files, for example at "async13/Demos/snippets/testHsolve.py" the below error produces:
>>>
>>> =====================================
>>> on node 0, numNodes = 1, numCores = 12
>>> Info: Time to define moose classes:0
>>> Info: Time to initialize module:0.05
>>> Created 306 path=/n numData=1 isGlobal=0 baseType=Neutral
>>> Created 307 path=/n/compt numData=1 isGlobal=0 baseType=SymCompartment
>>> Created 308 path=/n/compt/Na numData=1 isGlobal=0 baseType=HHChannel
>>> Created 312 path=/n/compt/K numData=1 isGlobal=0 baseType=HHChannel
>>> Created 316 path=/n/compt/synInput numData=1 isGlobal=0 baseType=SpikeGen
>>> Created 317 path=/n[0]/shaft0 numData=1 isGlobal=0 baseType=SymCompartment
>>> Created 318 path=/n[0]/head0 numData=1 isGlobal=0 baseType=SymCompartment
>>> Created 319 path=/n[0]/head0[0]/gluR numData=1 isGlobal=0 baseType=SynChan
>>> Created 321 path=/n[0]/head0[0]/ca numData=1 isGlobal=0 baseType=CaConc
>>> 0: Shell::doAddMsg: Error: Failed to find field event on src: synInput
>>> Traceback (most recent call last):
>>> File "testHsolve.py", line 297, in <module>
>>> main()
>>> File "testHsolve.py", line 294, in main
>>> test_elec_alone()
>>> File "testHsolve.py", line 265, in test_elec_alone
>>> make_spiny_compt()
>>> File "testHsolve.py", line 243, in make_spiny_compt
>>> moose.connect( synInput, 'event', syn, 'addSpike', 'Single' )
>>> NameError: check field names and type compatibility.
>>>
>>> ======================================
>>>
>>> It seems that the finfoMap_ array at Cinfo.cpp:214 does not contains all object names.
>>>
>>>
>>>
>>>> Upi
>>>> Dear Saeed,
>>>> Please give script snippet where this happens. Also you might wish
>>>> to look in Demos/snippets for examples of the correct use of the function.
>>>> Best,
>>>> Upi
>>>> On Tuesday 29 April 2014 09:04 PM, Saeed Shariati wrote:
>>>>> Hi,
>>>>>
>>>>> At async13 branch, when it tries to use connect method, the below error
>>>>> throws away:
>>>>>
>>>>> 0: Shell::doAddMsg: Error: Failed to find field spike on src: cell_0
>>>>>
>>>>> It would be my please if you have a look at this.
>>>>>
>>>>> Bests,
>>>>> Saeed
>>>>> ------------------------------------------------------------------------------
>>>>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>>>>> Instantly run your Selenium tests across 300+ browser/OS combos. Get
>>>>> unparalleled scalability from the best Selenium testing platform available.
>>>>> Simple to use. Nothing to install. Get started now for free."
>>>>> http://p.sf.net/sfu/SauceLabs
>>>>> _______________________________________________
>>>>> moose-devel mailing list
>>>>> moose-devel@...
>>>>> https://lists.sourceforge.net/lists/listinfo/moose-devel
>>>
>>> ------------------------------------------------------------------------------
>>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>>> Instantly run your Selenium tests across 300+ browser/OS combos. Get
>>> unparalleled scalability from the best Selenium testing platform available.
>>> Simple to use. Nothing to install. Get started now for free."
>>> http://p.sf.net/sfu/SauceLabs
>>> _______________________________________________
>>> moose-devel mailing list
>>> moo...@li...
>>> https://lists.sourceforge.net/lists/listinfo/moose-devel
>> ------------------------------------------------------------------------------
>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>> Instantly run your Selenium tests across 300+ browser/OS combos. Get
>> unparalleled scalability from the best Selenium testing platform available.
>> Simple to use. Nothing to install. Get started now for free."
>> http://p.sf.net/sfu/SauceLabs
>> _______________________________________________
>> moose-devel mailing list
>> moo...@li...
>> https://lists.sourceforge.net/lists/listinfo/moose-devel
>>
>>
>
>
>------------------------------------------------------------------------------
>"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>Instantly run your Selenium tests across 300+ browser/OS combos. Get
>unparalleled scalability from the best Selenium testing platform available.
>Simple to use. Nothing to install. Get started now for free."
>http://p.sf.net/sfu/SauceLabs
>_______________________________________________
>moose-devel mailing list
>moo...@li...
>https://lists.sourceforge.net/lists/listinfo/moose-devel
|
|
From: U.S.Bhalla <bh...@nc...> - 2014-04-30 04:57:14
|
Dear Dave,
Perhaps you could remind me what the optimizations were that the
Hsolve did for spike delivery in GENESIS. Was it simply that when the
spike event occurred, it directly went and called the spike delivery
methods of the target synapses, which were themselves under Hsolve?
In any event, the current MOOSE implementation uses regular messaging to
handle spike events. There is some optimization of messaging for
multinode models, but we haven't yet looked at putting the entire
network under a solver. First step would be to ask how much time is
actually spent delivering the spikes. Then it would be interesting to
compare with an equivalent model. Any suggestions?
Best,
Upi
On Wednesday 30 April 2014 01:34 AM, Dave Beeman wrote:
> I will be very interested in trying out the MOOSE Python implemention
> of hsolved when it is fully ready.
>
> In GENESIS 2, hsolve performs both the functions of a Hines method
> compartmental solver, and of a Discrete Event Solver for the efficient
> delivery of spike messages. Ideally, these should be in separate solvers,
> as they are in GENESIS 3 (unfortunately still under development).
>
> How is this being handled in MOOSE? Can networks of hsolved cells
> in MOOSE benefit from equivalent optimizations in spike delivery that
> GENESIS hsolve gives? Or is a separate mechanism used for spike delivery?
>
> On Tue, 29 Apr 2014, Dilawar Singh wrote:
>
>> Hi Saeed,
>>
>> We are in process of integrating 'hsolve' into async13 branch. Only today, I
>> got some sanity check of hsolve working. I am not sure how long it will take
>> to get hsolve properly integrated with python.
>>
>> For time being -- if you want to use async13 branch -- you can change the
>> solver to 'ee' from 'hsolve'.
>>
>> I'll let you know as soon as hsolve is ready.
>>
>> Dilawar
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> moose-devel mailing list
> moo...@li...
> https://lists.sourceforge.net/lists/listinfo/moose-devel
|
|
From: Subhasis R. <ray...@gm...> - 2014-04-30 05:42:26
|
Hi,
More specifically the error is due to incorrect field name, as the error
message suggests. The field name is 'spikeOut' and the snippet had not been
updated to reflect the change in naming.
Please note that we have settled on some naming conventions for fields
since async13 branch.
In particular, all source fields are suffixed 'Out' unless the field name
itself is output. Many of the old snippets and demos have been copied over
to the async13 branch but not yet updated to follow the new naming
convention and hence this error.
You can check the available field names using moose.doc() function in
Python which displays the class documentation and a list of fields, like
this:
>>> moose.doc('Compartment')
If you want to display the documentation for a particular field, then
append the field name with a dot as separator:
>>> moose.doc('Compartment.Vm')
I made some fixes to docstring generation, so please update before reading
the docs.
Best,
- Subhasis
( ʃʊbʱaːʃɪʃ )
On Tue, Apr 29, 2014 at 11:32 PM, Dilawar Singh <dil...@nc...>wrote:
> Hi Saeed,
>
> We are in process of integrating 'hsolve' into async13 branch. Only
> today, I
> got some sanity check of hsolve working. I am not sure how long it
> will take
> to get hsolve properly integrated with python.
>
> For time being -- if you want to use async13 branch -- you can change
> the
> solver to 'ee' from 'hsolve'.
>
> I'll let you know as soon as hsolve is ready.
>
> Dilawar
>
> On Tue, Apr 29, 2014 at 02:58:28PM -0300, Saeed wrote:
> >Sure, Sorry for the lack of information.
> >As I found it happens in many of Demo files, for example at
> "async13/Demos/snippets/testHsolve.py" the below error produces:
> >
> >=====================================
> >on node 0, numNodes = 1, numCores = 12
> >Info: Time to define moose classes:0
> >Info: Time to initialize module:0.05
> >Created 306 path=/n numData=1 isGlobal=0 baseType=Neutral
> >Created 307 path=/n/compt numData=1 isGlobal=0 baseType=SymCompartment
> >Created 308 path=/n/compt/Na numData=1 isGlobal=0 baseType=HHChannel
> >Created 312 path=/n/compt/K numData=1 isGlobal=0 baseType=HHChannel
> >Created 316 path=/n/compt/synInput numData=1 isGlobal=0 baseType=SpikeGen
> >Created 317 path=/n[0]/shaft0 numData=1 isGlobal=0 baseType=SymCompartment
> >Created 318 path=/n[0]/head0 numData=1 isGlobal=0 baseType=SymCompartment
> >Created 319 path=/n[0]/head0[0]/gluR numData=1 isGlobal=0 baseType=SynChan
> >Created 321 path=/n[0]/head0[0]/ca numData=1 isGlobal=0 baseType=CaConc
> >0: Shell::doAddMsg: Error: Failed to find field event on src: synInput
> >Traceback (most recent call last):
> > File "testHsolve.py", line 297, in <module>
> > main()
> > File "testHsolve.py", line 294, in main
> > test_elec_alone()
> > File "testHsolve.py", line 265, in test_elec_alone
> > make_spiny_compt()
> > File "testHsolve.py", line 243, in make_spiny_compt
> > moose.connect( synInput, 'event', syn, 'addSpike', 'Single' )
> >NameError: check field names and type compatibility.
> >
> >======================================
> >
> >It seems that the finfoMap_ array at Cinfo.cpp:214 does not contains all
> object names.
> >
> >
> >
> >>Upi
> >> Dear Saeed,
> >> Please give script snippet where this happens. Also you might wish
> >> to look in Demos/snippets for examples of the correct use of the
> function.
> >> Best,
> >> Upi
> >> On Tuesday 29 April 2014 09:04 PM, Saeed Shariati wrote:
> >>> Hi,
> >>>
> >>> At async13 branch, when it tries to use connect method, the below error
> >>> throws away:
> >>>
> >>> 0: Shell::doAddMsg: Error: Failed to find field spike on src: cell_0
> >>>
> >>> It would be my please if you have a look at this.
> >>>
> >>> Bests,
> >>> Saeed
> >>>
> ------------------------------------------------------------------------------
> >>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> >>> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> >>> unparalleled scalability from the best Selenium testing platform
> available.
> >>> Simple to use. Nothing to install. Get started now for free."
> >>>http://p.sf.net/sfu/SauceLabs
> >>> _______________________________________________
> >>> moose-devel mailing list
> >>> moose-devel@...
> >>>https://lists.sourceforge.net/lists/listinfo/moose-devel
> >
> >
>
> >------------------------------------------------------------------------------
> >"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> >Instantly run your Selenium tests across 300+ browser/OS combos. Get
> >unparalleled scalability from the best Selenium testing platform
> available.
> >Simple to use. Nothing to install. Get started now for free."
> >http://p.sf.net/sfu/SauceLabs
> >_______________________________________________
> >moose-devel mailing list
> >moo...@li...
> >https://lists.sourceforge.net/lists/listinfo/moose-devel
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> moose-devel mailing list
> moo...@li...
> https://lists.sourceforge.net/lists/listinfo/moose-devel
>
|
|
From: Saeed <sa...@gn...> - 2014-04-30 18:21:51
|
Thank you Subhasis, It was very helpful.
I know that the code is under development and I should not expect
correct execution at this moment. But my problem is that I suggested to
some students to have performance analysis on the Moose for their class
project. Their deadline is quite close and I want to give them a small
model and a version of Moose that is work enough for applying
performance tests.
It would be my great pleasure if you could tell me which kind of test
cases you have used for testing the parallel execution. For example if
one of the snippets are suitable for these test, would be great. Also,
do you know any revision of the async13 which is working and suitable
for parallel test?
For example the last code of async13 has some missed files such as
boost, global.cpp, etc. I just added files from other branches and I do
not know are they correct version or not. By the way it compiled, but in
simulation the below errors occur:
bin: 101
Error: bin:101t: 1921.01 currTime_ 1920 dt_: 0.01
Simulated till 1930. Left: 70. 10 of simulation took: 0.016554 s
bin: 101
Error: bin:101t: 1931.01 currTime_ 1930 dt_: 0.01
Simulated till 1940. Left: 60. 10 of simulation took: 0.016555 s
bin: 101
Error: bin:101t: 1941.01 currTime_ 1940 dt_: 0.01
It can be possibly the result of changes which I made in the code.
Thank you very much in advance
On 30-04-2014 02:41, Subhasis Ray wrote:
> Hi,
> More specifically the error is due to incorrect field name, as the error
> message suggests. The field name is 'spikeOut' and the snippet had not been
> updated to reflect the change in naming.
>
> Please note that we have settled on some naming conventions for fields
> since async13 branch.
> In particular, all source fields are suffixed 'Out' unless the field name
> itself is output. Many of the old snippets and demos have been copied over
> to the async13 branch but not yet updated to follow the new naming
> convention and hence this error.
>
> You can check the available field names using moose.doc() function in
> Python which displays the class documentation and a list of fields, like
> this:
>
>>>> moose.doc('Compartment')
> If you want to display the documentation for a particular field, then
> append the field name with a dot as separator:
>
>>>> moose.doc('Compartment.Vm')
> I made some fixes to docstring generation, so please update before reading
> the docs.
>
> Best,
> - Subhasis
> ( ʃʊbʱaːʃɪʃ )
>
>
> On Tue, Apr 29, 2014 at 11:32 PM, Dilawar Singh <dil...@nc...>wrote:
>
>> Hi Saeed,
>>
>> We are in process of integrating 'hsolve' into async13 branch. Only
>> today, I
>> got some sanity check of hsolve working. I am not sure how long it
>> will take
>> to get hsolve properly integrated with python.
>>
>> For time being -- if you want to use async13 branch -- you can change
>> the
>> solver to 'ee' from 'hsolve'.
>>
>> I'll let you know as soon as hsolve is ready.
>>
>> Dilawar
>>
>> On Tue, Apr 29, 2014 at 02:58:28PM -0300, Saeed wrote:
>>> Sure, Sorry for the lack of information.
>>> As I found it happens in many of Demo files, for example at
>> "async13/Demos/snippets/testHsolve.py" the below error produces:
>>> =====================================
>>> on node 0, numNodes = 1, numCores = 12
>>> Info: Time to define moose classes:0
>>> Info: Time to initialize module:0.05
>>> Created 306 path=/n numData=1 isGlobal=0 baseType=Neutral
>>> Created 307 path=/n/compt numData=1 isGlobal=0 baseType=SymCompartment
>>> Created 308 path=/n/compt/Na numData=1 isGlobal=0 baseType=HHChannel
>>> Created 312 path=/n/compt/K numData=1 isGlobal=0 baseType=HHChannel
>>> Created 316 path=/n/compt/synInput numData=1 isGlobal=0 baseType=SpikeGen
>>> Created 317 path=/n[0]/shaft0 numData=1 isGlobal=0 baseType=SymCompartment
>>> Created 318 path=/n[0]/head0 numData=1 isGlobal=0 baseType=SymCompartment
>>> Created 319 path=/n[0]/head0[0]/gluR numData=1 isGlobal=0 baseType=SynChan
>>> Created 321 path=/n[0]/head0[0]/ca numData=1 isGlobal=0 baseType=CaConc
>>> 0: Shell::doAddMsg: Error: Failed to find field event on src: synInput
>>> Traceback (most recent call last):
>>> File "testHsolve.py", line 297, in <module>
>>> main()
>>> File "testHsolve.py", line 294, in main
>>> test_elec_alone()
>>> File "testHsolve.py", line 265, in test_elec_alone
>>> make_spiny_compt()
>>> File "testHsolve.py", line 243, in make_spiny_compt
>>> moose.connect( synInput, 'event', syn, 'addSpike', 'Single' )
>>> NameError: check field names and type compatibility.
>>>
>>> ======================================
>>>
>>> It seems that the finfoMap_ array at Cinfo.cpp:214 does not contains all
>> object names.
>>>
>>>
>>>> Upi
>>>> Dear Saeed,
>>>> Please give script snippet where this happens. Also you might wish
>>>> to look in Demos/snippets for examples of the correct use of the
>> function.
>>>> Best,
>>>> Upi
>>>> On Tuesday 29 April 2014 09:04 PM, Saeed Shariati wrote:
>>>>> Hi,
>>>>>
>>>>> At async13 branch, when it tries to use connect method, the below error
>>>>> throws away:
>>>>>
>>>>> 0: Shell::doAddMsg: Error: Failed to find field spike on src: cell_0
>>>>>
>>>>> It would be my please if you have a look at this.
>>>>>
>>>>> Bests,
>>>>> Saeed
>>>>>
>> ------------------------------------------------------------------------------
>>>>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>>>>> Instantly run your Selenium tests across 300+ browser/OS combos. Get
>>>>> unparalleled scalability from the best Selenium testing platform
>> available.
>>>>> Simple to use. Nothing to install. Get started now for free."
>>>>> http://p.sf.net/sfu/SauceLabs
>>>>> _______________________________________________
>>>>> moose-devel mailing list
>>>>> moose-devel@...
>>>>> https://lists.sourceforge.net/lists/listinfo/moose-devel
>>>
>>> ------------------------------------------------------------------------------
>>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>>> Instantly run your Selenium tests across 300+ browser/OS combos. Get
>>> unparalleled scalability from the best Selenium testing platform
>> available.
>>> Simple to use. Nothing to install. Get started now for free."
>>> http://p.sf.net/sfu/SauceLabs
>>> _______________________________________________
>>> moose-devel mailing list
>>> moo...@li...
>>> https://lists.sourceforge.net/lists/listinfo/moose-devel
>>
>> ------------------------------------------------------------------------------
>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>> Instantly run your Selenium tests across 300+ browser/OS combos. Get
>> unparalleled scalability from the best Selenium testing platform available.
>> Simple to use. Nothing to install. Get started now for free."
>> http://p.sf.net/sfu/SauceLabs
>> _______________________________________________
>> moose-devel mailing list
>> moo...@li...
>> https://lists.sourceforge.net/lists/listinfo/moose-devel
>>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> moose-devel mailing list
> moo...@li...
> https://lists.sourceforge.net/lists/listinfo/moose-devel
|
|
From: Dilawar S. <dil...@nc...> - 2014-05-01 04:32:32
|
>For example the last code of async13 has some missed files such as
>boost, global.cpp, etc. I just added files from other branches and I do
>not know are they correct version or not. By the way it compiled, but in
>simulation the below errors occur:
>
> bin: 101
> Error: bin:101t: 1921.01 currTime_ 1920 dt_: 0.01
> Simulated till 1930. Left: 70. 10 of simulation took: 0.016554 s
> bin: 101
> Error: bin:101t: 1931.01 currTime_ 1930 dt_: 0.01
> Simulated till 1940. Left: 60. 10 of simulation took: 0.016555 s
> bin: 101
> Error: bin:101t: 1941.01 currTime_ 1940 dt_: 0.01
>
>It can be possibly the result of changes which I made in the code.
Hi Saeed,
I made these changes for debugging purpose. Unfortunately I committed them
without protecting the original code with suitable macros.
There is some problem is bin-size, it is getting bigger than MAXBIN size
when you execute testHsolve.py file. If you pass smaller time to
moose.start() then this problem goes away.
There is also some issue with paths in hsolve folder. I am trying to resolve
it.
Dilawar
|
|
From: Subhasis R. <ray...@gm...> - 2014-05-01 05:15:00
|
On Wed, Apr 30, 2014 at 11:51 PM, Saeed <sa...@gn...> wrote: > > It would be my great pleasure if you could tell me which kind of test > cases you have used for testing the parallel execution. For example if > one of the snippets are suitable for these test, would be great. Also, > do you know any revision of the async13 which is working and suitable > for parallel test? > Look inside tests/python/mpi. I have done this on a single host with a multicore CPU. You may want to change the hostfile for your specific case. Best, Subhasis |
|
From: Saeed S. <sa...@gn...> - 2014-05-01 21:05:50
|
On 05/01/2014 02:14 AM, Subhasis Ray wrote: > On Wed, Apr 30, 2014 at 11:51 PM, Saeed <sa...@gn...> wrote: > >> It would be my great pleasure if you could tell me which kind of test >> cases you have used for testing the parallel execution. For example if >> one of the snippets are suitable for these test, would be great. Also, >> do you know any revision of the async13 which is working and suitable >> for parallel test? >> > Look inside tests/python/mpi. I have done this on a single host with a > multicore CPU. You may want to change the hostfile for your specific case. > Best, > Subhasis > ------------------------------------------------------------------------------ > Thank you Subhasis. Please tell me if I am wrong. These test has been made for testing functionality and performance of simultaneous independent processes and at this moment, there is no communication between these processes. Also there is no communication between python processes and the moose executable file. I am wondering what is the MPI architecture and how the GPU part can be compatible with it. If you can guide me to any documentation, I appreciate it. I have some questions about architectural compatibility that will ask them trough a different thread. |
|
From: Subhasis R. <ray...@gm...> - 2014-05-02 11:58:31
|
On Fri, May 2, 2014 at 2:34 AM, Saeed Shariati <sa...@gn...> wrote: > > On 05/01/2014 02:14 AM, Subhasis Ray wrote: > > On Wed, Apr 30, 2014 at 11:51 PM, Saeed <sa...@gn...> wrote: > > > >> It would be my great pleasure if you could tell me which kind of test > >> cases you have used for testing the parallel execution. For example if > >> one of the snippets are suitable for these test, would be great. Also, > >> do you know any revision of the async13 which is working and suitable > >> for parallel test? > >> > > Look inside tests/python/mpi. I have done this on a single host with a > > multicore CPU. You may want to change the hostfile for your specific > case. > > Best, > > Subhasis > > > ------------------------------------------------------------------------------ > > > Thank you Subhasis. Please tell me if I am wrong. These test has been > made for testing functionality and performance of simultaneous > independent processes and at this moment, there is no communication > between these processes. Also there is no communication between python > processes and the moose executable file. > There IS communication between the different processes (including Python which is on the master node) via mpi and as far as I remember, it showed decent scaling with number of processes in that test. Best, - Subhasis ( ʃʊbʱaːʃɪʃ ) |
|
From: U.S.Bhalla <bh...@nc...> - 2014-05-02 12:01:23
|
Dear Saeed,
The following command runs a test integrate-and-fire network in
parallel on 6 nodes:
mpirun -np 1 python recurrentIntFire.py : -np 5 ../../../moose
The master node runs the version that talks to python, and the worker
nodes run the version without any python bindings because they receive
their instructions from the master node.
This is run as Subha says, in the tests/python/mpi directory.
The network has extensive communication between the 6 nodes.
Do let me know if this works for you.
Best,
Upi
On Friday 02 May 2014 02:34 AM, Saeed Shariati wrote:
> On 05/01/2014 02:14 AM, Subhasis Ray wrote:
>> On Wed, Apr 30, 2014 at 11:51 PM, Saeed <sa...@gn...> wrote:
>>
>>> It would be my great pleasure if you could tell me which kind of test
>>> cases you have used for testing the parallel execution. For example if
>>> one of the snippets are suitable for these test, would be great. Also,
>>> do you know any revision of the async13 which is working and suitable
>>> for parallel test?
>>>
>> Look inside tests/python/mpi. I have done this on a single host with a
>> multicore CPU. You may want to change the hostfile for your specific case.
>> Best,
>> Subhasis
>> ------------------------------------------------------------------------------
>>
> Thank you Subhasis. Please tell me if I am wrong. These test has been
> made for testing functionality and performance of simultaneous
> independent processes and at this moment, there is no communication
> between these processes. Also there is no communication between python
> processes and the moose executable file.
>
> I am wondering what is the MPI architecture and how the GPU part can be
> compatible with it. If you can guide me to any documentation, I
> appreciate it.
> I have some questions about architectural compatibility that will ask
> them trough a different thread.
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> moose-devel mailing list
> moo...@li...
> https://lists.sourceforge.net/lists/listinfo/moose-devel
|
|
From: Saeed S. <sa...@gn...> - 2014-05-02 22:24:16
|
Dear Upi and Subhasis,
Thank you. It was my mistake and I forgot that for using MPI, it
should be compiled with BUILD=mpi or ompi flag.
But, after executing "mpirun -np 1 python recurrentIntFire.py : -np
4 ../../../moose", all of the processors remains to work 100% busy,
everlastingly.
I reduced the model, but it still remains busy.
Saeed
On 05/02/2014 09:01 AM, U.S.Bhalla wrote:
> Dear Saeed,
> The following command runs a test integrate-and-fire network in
> parallel on 6 nodes:
>
> mpirun -np 1 python recurrentIntFire.py : -np 5 ../../../moose
>
> The master node runs the version that talks to python, and the worker
> nodes run the version without any python bindings because they receive
> their instructions from the master node.
>
> This is run as Subha says, in the tests/python/mpi directory.
>
> The network has extensive communication between the 6 nodes.
>
> Do let me know if this works for you.
>
> Best,
> Upi
>
>
> On Friday 02 May 2014 02:34 AM, Saeed Shariati wrote:
>> On 05/01/2014 02:14 AM, Subhasis Ray wrote:
>>> On Wed, Apr 30, 2014 at 11:51 PM, Saeed <sa...@gn...> wrote:
>>>
>>>> It would be my great pleasure if you could tell me which kind of test
>>>> cases you have used for testing the parallel execution. For example if
>>>> one of the snippets are suitable for these test, would be great. Also,
>>>> do you know any revision of the async13 which is working and suitable
>>>> for parallel test?
>>>>
>>> Look inside tests/python/mpi. I have done this on a single host with a
>>> multicore CPU. You may want to change the hostfile for your specific case.
>>> Best,
>>> Subhasis
>>> ------------------------------------------------------------------------------
>>>
>> Thank you Subhasis. Please tell me if I am wrong. These test has been
>> made for testing functionality and performance of simultaneous
>> independent processes and at this moment, there is no communication
>> between these processes. Also there is no communication between python
>> processes and the moose executable file.
>>
>> I am wondering what is the MPI architecture and how the GPU part can be
>> compatible with it. If you can guide me to any documentation, I
>> appreciate it.
>> I have some questions about architectural compatibility that will ask
>> them trough a different thread.
>>
>>
>> ------------------------------------------------------------------------------
>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>> Instantly run your Selenium tests across 300+ browser/OS combos. Get
>> unparalleled scalability from the best Selenium testing platform available.
>> Simple to use. Nothing to install. Get started now for free."
>> http://p.sf.net/sfu/SauceLabs
>> _______________________________________________
>> moose-devel mailing list
>> moo...@li...
>> https://lists.sourceforge.net/lists/listinfo/moose-devel
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> moose-devel mailing list
> moo...@li...
> https://lists.sourceforge.net/lists/listinfo/moose-devel
>
>
|
|
From: U.S.Bhalla <bh...@nc...> - 2014-05-03 03:40:49
|
Dear Saeed,
My understanding is that the Open MPI implementation uses a
busy-loop to poll for MPI requests and as long as the process is running
it will utilize 100% cpu on all processors deployed to use MPI.
Best,
Upi
On Saturday 03 May 2014 03:53 AM, Saeed Shariati wrote:
> Dear Upi and Subhasis,
>
> Thank you. It was my mistake and I forgot that for using MPI, it
> should be compiled with BUILD=mpi or ompi flag.
> But, after executing "mpirun -np 1 python recurrentIntFire.py : -np
> 4 ../../../moose", all of the processors remains to work 100% busy,
> everlastingly.
> I reduced the model, but it still remains busy.
>
> Saeed
>
> On 05/02/2014 09:01 AM, U.S.Bhalla wrote:
>> Dear Saeed,
>> The following command runs a test integrate-and-fire network in
>> parallel on 6 nodes:
>>
>> mpirun -np 1 python recurrentIntFire.py : -np 5 ../../../moose
>>
>> The master node runs the version that talks to python, and the worker
>> nodes run the version without any python bindings because they receive
>> their instructions from the master node.
>>
>> This is run as Subha says, in the tests/python/mpi directory.
>>
>> The network has extensive communication between the 6 nodes.
>>
>> Do let me know if this works for you.
>>
>> Best,
>> Upi
>>
>>
>> On Friday 02 May 2014 02:34 AM, Saeed Shariati wrote:
>>> On 05/01/2014 02:14 AM, Subhasis Ray wrote:
>>>> On Wed, Apr 30, 2014 at 11:51 PM, Saeed <sa...@gn...> wrote:
>>>>
>>>>> It would be my great pleasure if you could tell me which kind of test
>>>>> cases you have used for testing the parallel execution. For example if
>>>>> one of the snippets are suitable for these test, would be great. Also,
>>>>> do you know any revision of the async13 which is working and suitable
>>>>> for parallel test?
>>>>>
>>>> Look inside tests/python/mpi. I have done this on a single host with a
>>>> multicore CPU. You may want to change the hostfile for your specific case.
>>>> Best,
>>>> Subhasis
>>>> ------------------------------------------------------------------------------
>>>>
>>> Thank you Subhasis. Please tell me if I am wrong. These test has been
>>> made for testing functionality and performance of simultaneous
>>> independent processes and at this moment, there is no communication
>>> between these processes. Also there is no communication between python
>>> processes and the moose executable file.
>>>
>>> I am wondering what is the MPI architecture and how the GPU part can be
>>> compatible with it. If you can guide me to any documentation, I
>>> appreciate it.
>>> I have some questions about architectural compatibility that will ask
>>> them trough a different thread.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>>> Instantly run your Selenium tests across 300+ browser/OS combos. Get
>>> unparalleled scalability from the best Selenium testing platform available.
>>> Simple to use. Nothing to install. Get started now for free."
>>> http://p.sf.net/sfu/SauceLabs
>>> _______________________________________________
>>> moose-devel mailing list
>>> moo...@li...
>>> https://lists.sourceforge.net/lists/listinfo/moose-devel
>> ------------------------------------------------------------------------------
>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>> Instantly run your Selenium tests across 300+ browser/OS combos. Get
>> unparalleled scalability from the best Selenium testing platform available.
>> Simple to use. Nothing to install. Get started now for free."
>> http://p.sf.net/sfu/SauceLabs
>> _______________________________________________
>> moose-devel mailing list
>> moo...@li...
>> https://lists.sourceforge.net/lists/listinfo/moose-devel
>>
>>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> moose-devel mailing list
> moo...@li...
> https://lists.sourceforge.net/lists/listinfo/moose-devel
|
|
From: Saeed S. <sa...@gn...> - 2014-05-03 22:03:04
|
Thank you. We just realized that it happened because our compiler was mpich2. By replacing it with OpenMPI everything seems to work. On 05/03/2014 12:40 AM, U.S.Bhalla wrote: > Dear Saeed, > My understanding is that the Open MPI implementation uses a > busy-loop to poll for MPI requests and as long as the process is running > it will utilize 100% cpu on all processors deployed to use MPI. > > Best, > Upi > > On Saturday 03 May 2014 03:53 AM, Saeed Shariati wrote: >> Dear Upi and Subhasis, >> >> Thank you. It was my mistake and I forgot that for using MPI, it >> should be compiled with BUILD=mpi or ompi flag. >> But, after executing "mpirun -np 1 python recurrentIntFire.py : -np >> 4 ../../../moose", all of the processors remains to work 100% busy, >> everlastingly. >> I reduced the model, but it still remains busy. >> >> Saeed >> >> On 05/02/2014 09:01 AM, U.S.Bhalla wrote: >>> Dear Saeed, >>> The following command runs a test integrate-and-fire network in >>> parallel on 6 nodes: >>> >>> mpirun -np 1 python recurrentIntFire.py : -np 5 ../../../moose >>> >>> The master node runs the version that talks to python, and the worker >>> nodes run the version without any python bindings because they receive >>> their instructions from the master node. >>> >>> This is run as Subha says, in the tests/python/mpi directory. >>> >>> The network has extensive communication between the 6 nodes. >>> >>> Do let me know if this works for you. >>> >>> Best, >>> Upi >>> >>> >>> On Friday 02 May 2014 02:34 AM, Saeed Shariati wrote: >>>> On 05/01/2014 02:14 AM, Subhasis Ray wrote: >>>>> On Wed, Apr 30, 2014 at 11:51 PM, Saeed <sa...@gn...> wrote: >>>>> >>>>>> It would be my great pleasure if you could tell me which kind of test >>>>>> cases you have used for testing the parallel execution. For example if >>>>>> one of the snippets are suitable for these test, would be great. Also, >>>>>> do you know any revision of the async13 which is working and suitable >>>>>> for parallel test? >>>>>> >>>>> Look inside tests/python/mpi. I have done this on a single host with a >>>>> multicore CPU. You may want to change the hostfile for your specific case. >>>>> Best, >>>>> Subhasis >>>>> ------------------------------------------------------------------------------ >>>>> >>>> Thank you Subhasis. Please tell me if I am wrong. These test has been >>>> made for testing functionality and performance of simultaneous >>>> independent processes and at this moment, there is no communication >>>> between these processes. Also there is no communication between python >>>> processes and the moose executable file. >>>> >>>> I am wondering what is the MPI architecture and how the GPU part can be >>>> compatible with it. If you can guide me to any documentation, I >>>> appreciate it. >>>> I have some questions about architectural compatibility that will ask >>>> them trough a different thread. >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE >>>> Instantly run your Selenium tests across 300+ browser/OS combos. Get >>>> unparalleled scalability from the best Selenium testing platform available. >>>> Simple to use. Nothing to install. Get started now for free." >>>> http://p.sf.net/sfu/SauceLabs >>>> _______________________________________________ >>>> moose-devel mailing list >>>> moo...@li... >>>> https://lists.sourceforge.net/lists/listinfo/moose-devel >>> ------------------------------------------------------------------------------ >>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE >>> Instantly run your Selenium tests across 300+ browser/OS combos. Get >>> unparalleled scalability from the best Selenium testing platform available. >>> Simple to use. Nothing to install. Get started now for free." >>> http://p.sf.net/sfu/SauceLabs >>> _______________________________________________ >>> moose-devel mailing list >>> moo...@li... >>> https://lists.sourceforge.net/lists/listinfo/moose-devel >>> >>> >> ------------------------------------------------------------------------------ >> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE >> Instantly run your Selenium tests across 300+ browser/OS combos. Get >> unparalleled scalability from the best Selenium testing platform available. >> Simple to use. Nothing to install. Get started now for free." >> http://p.sf.net/sfu/SauceLabs >> _______________________________________________ >> moose-devel mailing list >> moo...@li... >> https://lists.sourceforge.net/lists/listinfo/moose-devel > > ------------------------------------------------------------------------------ > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. Get > unparalleled scalability from the best Selenium testing platform available. > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > _______________________________________________ > moose-devel mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moose-devel > > |
|
From: Dave B. <db...@Co...> - 2014-04-30 23:25:50
|
Hi Upi and other MOOSE developers, I will do my best to answer your questio of how GENESIS 2 hsolve deals with spike delivery, but you will get a better answer from Hugo Cornelis, who I have copied on this email. Hugo wrote a detailed tutorial document on hsolve back in 2002 for the GUM meeting. http://genesis-sim.org/GENESIS/UGTD/Tutorials/advanced-tutorials/hsolve-cornelis/index.html The section on Synchan - hsolve coordination tells something of how it works. It was only about two years ago that I got around to reading the section on networks of cells that I tried using hsolve on my network models. None of all the large GENESIS network models that I have seen use hsolve, except in chanmode 0 or 1. I did not expect a significant speed improvement when I used hsolve chanmode 4 with my cortical model of 9-compartment cells. The speedup for the Purkinje cell model is only a factor of 4. I was amazed when my simulations ran 10 to 12 times faster. Recently I reimplemented the network benchmark that was used in the Brette et al 2007 paper using hsolve. The cells are single compartment with only Na and K channels, and the simulation ran 20 times faster. You can see an example of how hsolve is used in my auditory cortex model at http://genesis-sim.org/GENESIS/ACnet2-GENESIS/ Evidently, when hsolve deals with the interactions between spiegens and synchans it bypasses the overhead of the messaging, and that this overhead is very large. I think it is important that MOOSE implement communication in an efficient way to avoid this kind of speed penalty, whether it is done within the hsolve implementation or with a separate solver. >From my point of view as a modeler, the biggest limitation of GENESIS 2, other than its lack of a Python interface, is the difficulty of using hsolve for the non-expert, and the limitation on which objects can be used with hsolve. If MOOSE can overcome these problems and give speed equivalent to GENESIS 2, I would be happy to try my models on MOOSE when it is ready enough to make the conversion simple. Dave On Wed, 30 Apr 2014, U.S.Bhalla wrote: > Dear Dave, > Perhaps you could remind me what the optimizations were that the > Hsolve did for spike delivery in GENESIS. Was it simply that when the > spike event occurred, it directly went and called the spike delivery > methods of the target synapses, which were themselves under Hsolve? > > In any event, the current MOOSE implementation uses regular messaging to > handle spike events. There is some optimization of messaging for > multinode models, but we haven't yet looked at putting the entire > network under a solver. First step would be to ask how much time is > actually spent delivering the spikes. Then it would be interesting to > compare with an equivalent model. Any suggestions? > > Best, > Upi > > On Wednesday 30 April 2014 01:34 AM, Dave Beeman wrote: >> I will be very interested in trying out the MOOSE Python implemention >> of hsolved when it is fully ready. >> >> In GENESIS 2, hsolve performs both the functions of a Hines method >> compartmental solver, and of a Discrete Event Solver for the efficient >> delivery of spike messages. Ideally, these should be in separate solvers, >> as they are in GENESIS 3 (unfortunately still under development). >> >> How is this being handled in MOOSE? Can networks of hsolved cells >> in MOOSE benefit from equivalent optimizations in spike delivery that >> GENESIS hsolve gives? Or is a separate mechanism used for spike delivery? >> >> On Tue, 29 Apr 2014, Dilawar Singh wrote: >> >>> Hi Saeed, >>> >>> We are in process of integrating 'hsolve' into async13 branch. Only today, I >>> got some sanity check of hsolve working. I am not sure how long it will take >>> to get hsolve properly integrated with python. >>> >>> For time being -- if you want to use async13 branch -- you can change the >>> solver to 'ee' from 'hsolve'. >>> >>> I'll let you know as soon as hsolve is ready. >>> >>> Dilawar >> ------------------------------------------------------------------------------ >> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE >> Instantly run your Selenium tests across 300+ browser/OS combos. Get >> unparalleled scalability from the best Selenium testing platform available. >> Simple to use. Nothing to install. Get started now for free." >> http://p.sf.net/sfu/SauceLabs >> _______________________________________________ >> moose-devel mailing list >> moo...@li... >> https://lists.sourceforge.net/lists/listinfo/moose-devel > > > ------------------------------------------------------------------------------ > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. Get > unparalleled scalability from the best Selenium testing platform available. > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > _______________________________________________ > moose-devel mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moose-devel > |
|
From: Hugo C. <hug...@gm...> - 2014-05-01 09:14:27
|
Hi Dave, Upi and others, As Dave says, using hsolve comes with a significant performance improvement for event processing. I analysed the performance of event processing in Genesis-2 in depth a long time ago, but, really, cannot remember all the details. There are two elements that may be important: If I remember well the speedup of event processing with hsolve comes mostly from avoiding pointer indirections of the Genesis-2 action handling system in the Genesis-2 core. The implementation of Genesis-2 actions is similar to the implementation of C++ method invocation. So my guess is that Moose may benefit from similar optimizations. Although I want to be careful with such statements, because I don't know that much about Moose internals, and, also, CPUs use speculative execution techniques to optimize for C++ method invocation. The second element is the choice of data structure for event queuing. The event queue can either be centralized, which is the approach taken by most of the papers in discrete event simulation, or it can be distributed, which is what Genesis-2 does. >From memory of an in-depth analysis and benchmarking at the time, I can say, without remembering the details, that none of these two alternatives had significant advantages over the other. Even given that the literature of discrete event simulation mentions splay trees and calendar queues as optimal, I believe, this is not what I found for neural simulations. This may be due to the highly dynamical temporal structure of the event queue during a simulation. I hope this helps. Hugo On Thu, May 1, 2014 at 1:25 AM, Dave Beeman <db...@co...> wrote: > Hi Upi and other MOOSE developers, > > I will do my best to answer your questio of how GENESIS 2 hsolve > deals with spike delivery, but you will get a better answer from Hugo > Cornelis, who I have copied on this email.the > > Hugo wrote a detailed tutorial document on hsolve back in 2002 for the GUM > meeting. > > http://genesis-sim.org/GENESIS/UGTD/Tutorials/advanced-tutorials/hsolve- > cornelis/index.html > > The section on Synchan - hsolve coordination tells something of how it > works. It was only about two years ago that I got around to reading > the section on networks of cells that I tried using hsolve on my network > models. None of all the large GENESIS network models that I have seen use > hsolve, except in chanmode 0 or 1. > > I did not expect a significant speed improvement when I used hsolve > chanmode 4 with my cortical model of 9-compartment cells. The speedup > for the Purkinje cell model is only a factor of 4. I was amazed when > my simulations ran 10 to 12 times faster. Recently I reimplemented > the network benchmark that was used in the Brette et al 2007 paper > using hsolve. The cells are single compartment with only Na and K > channels, and the simulation ran 20 times faster. > > You can see an example of how hsolve is used in my auditory cortex model at > http://genesis-sim.org/GENESIS/ACnet2-GENESIS/ > > Evidently, when hsolve deals with the interactions between spiegens and > synchans it bypasses the overhead of the messaging, and that this overhead > is very large. I think it is important that MOOSE implement communication > in an efficient way to avoid this kind of speed penalty, whether it is done > within the hsolve implementation or with a separate solver. > > From my point of view as a modeler, the biggest limitation of GENESIS 2, > other than its lack of a Python interface, is the difficulty of using > hsolve for the non-expert, and the limitation on which objects can > be used with hsolve. If MOOSE can overcome these problems and give > speed equivalent to GENESIS 2, I would be happy to try my models > on MOOSE when it is ready enough to make the conversion simple. > > Dave > > > > On Wed, 30 Apr 2014, U.S.Bhalla wrote: > > Dear Dave, >> Perhaps you could remind me what the optimizations were that the >> Hsolve did for spike delivery in GENESIS. Was it simply that when the >> spike event occurred, it directly went and called the spike delivery >> methods of the target synapses, which were themselves under Hsolve? >> >> In any event, the current MOOSE implementation uses regular messaging to >> handle spike events. There is some optimization of messaging for >> multinode models, but we haven't yet looked at putting the entire >> network under a solver. First step would be to ask how much time is >> actually spent delivering the spikes. Then it would be interesting to >> compare with an equivalent model. Any suggestions? >> >> Best, >> Upi >> >> On Wednesday 30 April 2014 01:34 AM, Dave Beeman wrote: >> >>> I will be very interested in trying out the MOOSE Python implemention >>> of hsolved when it is fully ready. >>> >>> In GENESIS 2, hsolve performs both the functions of a Hines method >>> compartmental solver, and of a Discrete Event Solver for the efficient >>> delivery of spike messages. Ideally, these should be in separate >>> solvers, >>> as they are in GENESIS 3 (unfortunately still under development). >>> >>> How is this being handled in MOOSE? Can networks of hsolved cells >>> in MOOSE benefit from equivalent optimizations in spike delivery that >>> GENESIS hsolve gives? Or is a separate mechanism used for spike >>> delivery? >>> >>> On Tue, 29 Apr 2014, Dilawar Singh wrote: >>> >>> Hi Saeed, >>>> >>>> We are in process of integrating 'hsolve' into async13 branch. >>>> Only today, I >>>> got some sanity check of hsolve working. I am not sure how long it >>>> will take >>>> to get hsolve properly integrated with python. >>>> >>>> For time being -- if you want to use async13 branch -- you can >>>> change the >>>> solver to 'ee' from 'hsolve'. >>>> >>>> I'll let you know as soon as hsolve is ready. >>>> >>>> Dilawar >>>> >>> ------------------------------------------------------------ >>> ------------------ >>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE >>> Instantly run your Selenium tests across 300+ browser/OS combos. Get >>> unparalleled scalability from the best Selenium testing platform >>> available. >>> Simple to use. Nothing to install. Get started now for free." >>> http://p.sf.net/sfu/SauceLabs >>> _______________________________________________ >>> moose-devel mailing list >>> moo...@li... >>> https://lists.sourceforge.net/lists/listinfo/moose-devel >>> >> >> >> ------------------------------------------------------------ >> ------------------ >> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE >> Instantly run your Selenium tests across 300+ browser/OS combos. Get >> unparalleled scalability from the best Selenium testing platform >> available. >> Simple to use. Nothing to install. Get started now for free." >> http://p.sf.net/sfu/SauceLabs >> _______________________________________________ >> moose-devel mailing list >> moo...@li... >> https://lists.sourceforge.net/lists/listinfo/moose-devel >> >> -- Hugo -- Hugo Cornelis Ph.D. GENESIS-3 -- lead architect http://www.genesis-sim.org/ Neurospaces Project Architect http://www.neurospaces.org/ |
|
From: U.S.Bhalla <bh...@nc...> - 2014-04-29 15:55:10
|
Dear Saeed,
Please give script snippet where this happens. Also you might wish
to look in Demos/snippets for examples of the correct use of the function.
Best,
Upi
On Tuesday 29 April 2014 09:04 PM, Saeed Shariati wrote:
> Hi,
>
> At async13 branch, when it tries to use connect method, the below error
> throws away:
>
> 0: Shell::doAddMsg: Error: Failed to find field spike on src: cell_0
>
> It would be my please if you have a look at this.
>
> Bests,
> Saeed
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> moose-devel mailing list
> moo...@li...
> https://lists.sourceforge.net/lists/listinfo/moose-devel
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X