You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(6) |
Jun
(8) |
Jul
(3) |
Aug
(27) |
Sep
(10) |
Oct
(1) |
Nov
(4) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(1) |
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(8) |
Dec
(8) |
2013 |
Jan
|
Feb
(2) |
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
(3) |
Aug
(1) |
Sep
(2) |
Oct
(2) |
Nov
(2) |
Dec
|
2014 |
Jan
|
Feb
(1) |
Mar
(13) |
Apr
(41) |
May
(20) |
Jun
(5) |
Jul
(5) |
Aug
|
Sep
(3) |
Oct
(4) |
Nov
|
Dec
|
2015 |
Jan
|
Feb
(3) |
Mar
(2) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Subhasis R. <ray...@gm...> - 2015-04-22 02:41:18
|
Dear Viktor, I apologize if you did not get a response to your message to the incf developers' list. I have not looked at your code and am not sure if your updates are against current moose trunk or the older version. In case it works with moose trunk, I would suggest that you do some tests and benchmarks and then merge to trunk. I think you may find some clues from existing implementation of hsolve. Look at "method" field of the hsolve object and reinit() function. For tests you can start with simple passive cable, passive tree, then the same topologies with hh channels and then synapses. For benchmarking, you can try the single cell models in demos/traub_2005. I have found it useful to run a program under gdb by setting break points at entrypoints and suspected execution paths and looking at stack traces and single stepping to figure out code written by other people. You can apply that when docs are not enough and the original developers are not accessible. Best, Subha On Apr 21, 2015 8:38 PM, "Viktor Tóth" <ben...@gm...> wrote: > Hi, > > I realized that my previous mail to the INCF list would be more appropriate > here. I have already optimized and simplified both the GpuSolver and > GpuLookup part of the GPGPU code base. Still, much need to be reconsidered > as I commented in the code. My updates can be found here: > https://github.com/csiki/moose-1/tree/gpu/hsolve > > Best, > Viktor Tóth > > ------------------------------------------------------------------------------ > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live > exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- > event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > _______________________________________________ > moose-devel mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moose-devel > |
From: Viktor T. <ben...@gm...> - 2015-04-22 00:38:40
|
Hi, I realized that my previous mail to the INCF list would be more appropriate here. I have already optimized and simplified both the GpuSolver and GpuLookup part of the GPGPU code base. Still, much need to be reconsidered as I commented in the code. My updates can be found here: https://github.com/csiki/moose-1/tree/gpu/hsolve Best, Viktor Tóth |
From: Subhasis R. <ray...@gm...> - 2015-03-31 15:23:17
|
Hi, This is more of a user issue than a development issue, hence cc to moose-generic mailing list. On Tue, Mar 31, 2015 at 4:38 AM, Dilawar Singh <dil...@nc...> wrote: > > An equation in chemical model is following: > > x(t) = a(t)*b(t)*c(t); (A) > > Variable 'x' is a proxy for three independent moose.Pool with species a, > b, and > c having their own kinetics. In other reactions, 'x' is treated as input; > What do you mean by input to a reaction? > therefor it should be implemented as moose.Pool or moose.BufPool. > > In continuation of previous query, can you tell us more about the reaction system? A pool is a pool of molecules and I cannot imagine the number of molecules in one pool being the product of three others in a physical process. In another way, your equation will be dimensionally invalid. > > AFAIK, currently moose.Pool does not have a Dest-Finfo which I can use to > set > the number of molecules in Pool. For each ValueFinfo 'x', a moose class automatically gets a 'getX' and 'setX' DestFinfos. You could see this using the builtin doc function: >>> moose.doc('Pool') ... *Destination message field* setN: double getN: PSt6vectorIdSaIdEE setNInit: double getNInit: PSt6vectorIdSaIdEE setDiffConst: double getDiffConst: PSt6vectorIdSaIdEE ... > I can only use 'increment' or 'decrement' which > is fine if the equation was: > > dx/dt = a*b*c (A1) > > So it boils down to having a moose.Pool where kinetics can be described > using > the equation (A); perhaps a combination of moose.Function and moose.Table. > But > in the end, I have to set the conc/n of moose.Pool using a message. > I am not sure if setting n externally is the right approach though. The pools are supposed to participate in reactions and get their n updated through that process. > > Another way of doing it to use the moose.Function and connect > 'getDerivative' to > the x (moose.Pool) 'increment'. I don't know if it would be mathematically > wrong > but moose.connect does not allow connecting these two Finfos. I can > implement > this if it is mathematically correct or does not cause numerical issues. > You cannot connect a DestFinfo to another DestFinfo. You can use 'derivativeOut' SrcFinfo from Function. > > I extended the moose.Pool class by adding a 'N' destinfo which set the n_ > to > given value As I mentioned above, this was unnecessary. > but I don't know what values should A_ and B_ take. Merely changing > n_ and setting A_ and B_ to 0 does give me correct shape of curves, but the > values are way too high (seems like conc is replaced by number of > molecules in > Pool). > What are A_ and B_ ? conc is calculated from the number of molecules in Pool and should be proportional. It is not clear what you are trying to model. I would suggest you review your model and see if chemical kinetics is really necessary. Best, Subhasis |
From: Dilawar S. <dil...@nc...> - 2015-03-31 08:38:06
|
Hi, An equation in chemical model is following: x(t) = a(t)*b(t)*c(t); (A) Variable 'x' is a proxy for three independent moose.Pool with species a, b, and c having their own kinetics. In other reactions, 'x' is treated as input; therefor it should be implemented as moose.Pool or moose.BufPool. AFAIK, currently moose.Pool does not have a Dest-Finfo which I can use to set the number of molecules in Pool. I can only use 'increment' or 'decrement' which is fine if the equation was: dx/dt = a*b*c (A1) So it boils down to having a moose.Pool where kinetics can be described using the equation (A); perhaps a combination of moose.Function and moose.Table. But in the end, I have to set the conc/n of moose.Pool using a message. Another way of doing it to use the moose.Function and connect 'getDerivative' to the x (moose.Pool) 'increment'. I don't know if it would be mathematically wrong but moose.connect does not allow connecting these two Finfos. I can implement this if it is mathematically correct or does not cause numerical issues. I extended the moose.Pool class by adding a 'N' destinfo which set the n_ to given value but I don't know what values should A_ and B_ take. Merely changing n_ and setting A_ and B_ to 0 does give me correct shape of curves, but the values are way too high (seems like conc is replaced by number of molecules in Pool). best, Dilawar |
From: Joanna Jedrzejewska-S. <jje...@gm...> - 2015-02-04 16:42:59
|
Dear Subhasis, Thank you for your e-mail. The problem about DifBuffer is this: To realistically model calcium dynamics one needs calcium diffusion, diffusible buffers and extrusion pumps. These mechanisms are implemented in following objects: DifShell, DifBuffer, and mmPump and hillPump (and possibly some other pumps), and modellers refer to them colloquially as "DifShells". Unfortunately DifShell objects alone are quite useless. If you add them, we'll be really grateful. Best regards, Joanna Jedrzejewska-Szmek ________________________________________ From: Subhasis Ray <ray...@gm...> Sent: Tuesday, February 3, 2015 8:44 PM To: Moose development issues Cc: Subhasis Ray Subject: Re: [moose-devel] DifShell and DifBuffer Hi, This has been a pending feature for quite some time. DifShell has a buffer message, but as you point out, the DifBuffer class has not been ported yet. I have added it to the issue tracker as a feature request and hopefully it will be added soon. Best, - Subhasis On Mon, Feb 2, 2015 at 2:24 PM, Zbigniew Jędrzejewski-Szmek < zje...@gm...> wrote: > Hi, > > DifShells seem to be missing DifBuffers. To simulate calcium dynamics > properly, > DifBuffers are required. Commits which added DifShell did not add that > part. > Calcium Pump objects are also missing. > > Thank you, > Zbyszek > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > moose-devel mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moose-devel > ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ moose-devel mailing list moo...@li... https://lists.sourceforge.net/lists/listinfo/moose-devel |
From: Subhasis R. <ray...@gm...> - 2015-02-04 02:45:08
|
Hi, This has been a pending feature for quite some time. DifShell has a buffer message, but as you point out, the DifBuffer class has not been ported yet. I have added it to the issue tracker as a feature request and hopefully it will be added soon. Best, - Subhasis On Mon, Feb 2, 2015 at 2:24 PM, Zbigniew Jędrzejewski-Szmek < zje...@gm...> wrote: > Hi, > > DifShells seem to be missing DifBuffers. To simulate calcium dynamics > properly, > DifBuffers are required. Commits which added DifShell did not add that > part. > Calcium Pump objects are also missing. > > Thank you, > Zbyszek > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > moose-devel mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moose-devel > |
From: Zbigniew Jędrzejewski-S. <zje...@gm...> - 2015-02-02 19:56:13
|
Hi, DifShells seem to be missing DifBuffers. To simulate calcium dynamics properly, DifBuffers are required. Commits which added DifShell did not add that part. Calcium Pump objects are also missing. Thank you, Zbyszek |
From: U.S.Bhalla <bh...@nc...> - 2014-10-16 14:39:39
|
Dear Saeed, Did you have a look at the branch that Vivek Sagar made for his GPU project? That worked under the current clock structure. I gather he launched GPU threads from within his section of the code. The clock itself executes in a single-thread manner. Best, Upi On Wednesday 15 October 2014 01:09 AM, Saeed Shariati wrote: > Dear All, > > The current version of the GPU version, executes in synchronous and single > thread mode and by each step, executes the GPU kernels and comes back. > Therefore, the performance significantly reduce. Beside of multithread > execution, using axonal delay can boost the performance by reducing number > of kernel call which is quite expensive in GPU execution. > > Would you please guide me how to use Clocking mechanism to obtain this > functionality? For Example I see in Clock::buildTicks() function, the > variable "stride_" is responsible for this parameter, but it seems that > this value hard-coded to one (1). > > Any clue or guidance would be appreciated. > > Thank you, > Saeed > ------------------------------------------------------------------------------ > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://p.sf.net/sfu/Zoho > _______________________________________________ > moose-devel mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moose-devel |
From: U.S.Bhalla <bh...@nc...> - 2014-10-16 14:37:50
|
Dear Saeed, We've been focussing on features, so the MPI execution may not work currently. We plan to get back to this soon. Best, Upi On Wednesday 15 October 2014 01:00 AM, Saeed Shariati wrote: > Dear All, > > I have some issues with the MPI execution of Model. Does it work in the > last updates? > Also, would you please guide me how to execute HSolve objects in MPI? > > Regards, > Saeed > ------------------------------------------------------------------------------ > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://p.sf.net/sfu/Zoho > _______________________________________________ > moose-devel mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moose-devel |
From: Saeed S. <sd....@gm...> - 2014-10-14 19:40:00
|
Dear All, The current version of the GPU version, executes in synchronous and single thread mode and by each step, executes the GPU kernels and comes back. Therefore, the performance significantly reduce. Beside of multithread execution, using axonal delay can boost the performance by reducing number of kernel call which is quite expensive in GPU execution. Would you please guide me how to use Clocking mechanism to obtain this functionality? For Example I see in Clock::buildTicks() function, the variable "stride_" is responsible for this parameter, but it seems that this value hard-coded to one (1). Any clue or guidance would be appreciated. Thank you, Saeed |
From: Saeed S. <sd....@gm...> - 2014-10-14 19:31:10
|
Dear All, I have some issues with the MPI execution of Model. Does it work in the last updates? Also, would you please guide me how to execute HSolve objects in MPI? Regards, Saeed |
From: Saeed S. <sd....@gm...> - 2014-09-24 16:48:55
|
Dear Upi, Thank you. I'll have a look at the Vivek's code. But so far, everything working properly. I did develop a Master Solver to get a bunch of model, put some parts in GPU and keep CPU parts intact. Therefore, the GPU version works beside of CPU and can extend gradually. The documentation is almost ready and I will send it soon. But still my main problem is to set benchmark and compare the performance. It would be my great pleasure if any of the moose developers guide me, how to simulate models with hsolve in parallel, efficiently. Best Regards, Saeed > Dear Saeed, > This is very good news! Vivek had gotten GPUs to run from MOOSE but > not the full implementation. Perhaps you may wish to look at his code to > see how to fold into MOOSE. > Best, > Upi > On Wednesday 24 September 2014 06:47 PM, Saeed Shariati wrote: > Dear all, > > The GPU version of HSolve is almost ready and I'll put codes in svn as soon > as solving some issues. > > But, to test the performance, I couldn't utilize Moose to run models with > hsolve objects in multicore systems. > > As an alternative, I could manage use MPI version available in _test_ > directory and assign an instance to each core. But it doesn't support > hsolves. > > Would you please guide me what is the best way to run moose on multicore > systems and afterwards cluster? > > Thank you in advance, > Best Regards, > Saeed > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > > _______________________________________________ > moose-devel mailing list > moose-devel@... > https://lists.sourceforge.net/lists/listinfo/moose-devel On Wed, Sep 24, 2014 at 10:17 AM, Saeed Shariati <sd....@gm...> wrote: > Dear all, > > The GPU version of HSolve is almost ready and I'll put codes in svn as > soon as solving some issues. > > But, to test the performance, I couldn't utilize Moose to run models with > hsolve objects in multicore systems. > > As an alternative, I could manage use MPI version available in _test_ > directory and assign an instance to each core. But it doesn't support > hsolves. > > Would you please guide me what is the best way to run moose on multicore > systems and afterwards cluster? > > Thank you in advance, > Best Regards, > Saeed > |
From: U.S.Bhalla <bh...@nc...> - 2014-09-24 15:01:14
|
Dear Saeed, This is very good news! Vivek had gotten GPUs to run from MOOSE but not the full implementation. Perhaps you may wish to look at his code to see how to fold into MOOSE. Best, Upi On Wednesday 24 September 2014 06:47 PM, Saeed Shariati wrote: > Dear all, > > The GPU version of HSolve is almost ready and I'll put codes in svn as soon > as solving some issues. > > But, to test the performance, I couldn't utilize Moose to run models with > hsolve objects in multicore systems. > > As an alternative, I could manage use MPI version available in _test_ > directory and assign an instance to each core. But it doesn't support > hsolves. > > Would you please guide me what is the best way to run moose on multicore > systems and afterwards cluster? > > Thank you in advance, > Best Regards, > Saeed > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > moose-devel mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moose-devel |
From: Saeed S. <sd....@gm...> - 2014-09-24 13:17:38
|
Dear all, The GPU version of HSolve is almost ready and I'll put codes in svn as soon as solving some issues. But, to test the performance, I couldn't utilize Moose to run models with hsolve objects in multicore systems. As an alternative, I could manage use MPI version available in _test_ directory and assign an instance to each core. But it doesn't support hsolves. Would you please guide me what is the best way to run moose on multicore systems and afterwards cluster? Thank you in advance, Best Regards, Saeed |
From: Dilawar S. <dil...@gm...> - 2014-07-30 17:06:01
|
Dear All, Currently moose-gui is in mgui folder. I propose the following to make the packaging consistent with general packaging policy on debian and rpm. Debian and RPM would accept this kind of layout also but PyPI will complain about it. 1. Move mgui to python/gui. This way everything pythonic in moose is in one place and can be passed easily to `setup.py` for building and installing. 2. Currently mgui scripts are not in standard python packaging format; lot of scripts are bundled together to make it work. It can not be installed using `python setup.py install`. One can only install it as inseparable part of moose which is also OK as long as we don't give preference to packaging. Currently, I copied mgui folder as python/gui and fixed few imports statement. Statements such as `import kkit` are changed to `from ..plugins import kkit`. One only has to change the import statements. One can test the development in usual way except that for launching gui when developing one should also pass `-m mgui` to tell python that this is in package. python -m mgui mgui.py instead of python mgui.py Currently this is what is being put in debian packages. Dilawar |
From: Subhasis R. <ray...@gm...> - 2014-07-04 05:21:46
|
Dear Saeed, (CC to Upi, Dilawar, Vivek, the developers involved with components related to this issue) On Fri, Jul 4, 2014 at 5:09 AM, saeed <sa...@gn...> wrote: > Application crashes with Assertion failure in SpikeRingBuffer.cpp:63 > and actually I just put the warning to maybe guide to the problem. > My change is not about the dt, after just a little increase in > simulation time (from 0.01 to 0.1) I see this problem. Sorry for overlooking this point in my hurry. The documentation in SpikeRingBuffer.h says: /** * This ring buffer handles incoming spikes. It spans an interval equal to * the longest arrival delay. When a spike event is notified it puts it into * the slot defined by the arrival time. It just adds the weight onto the * existing value in this slot, assuming a linear summation of the * weights of coincident inputs. */ It was designed to simplify storage of spike events coming with a specified delay period and each slot in the buffer corresponds to the time step in which it should be taken into account for computing the synaptic conductance. Given that axonal delays can be of the order of 100 ms on the slower side while dt is usually of the order of 100 us, I think we have a valid design issue here. Thanks for bringing this up. I am wondering, maybe SynChan is not working properly. I know that the > HSolve is still under control, but in other side I finished the GPU > implementation and for accuracy test, I need to make the Moose work. > Since SynChan is outside the purview of HSolve, you should not be hindered by this particular case. Also, hsolve seems to work for simple cases (like testHsolve and Rallpacks), though it has not been tested rigorously for complex neuron models. So you can try to plugin your code and check if the GPU code works for the simple cases first while Dilawar ties up the loose ends. Best, Subhasis > On 02-07-2014 15:25, Subhasis Ray wrote: > > Dear Saeed, > > You mean simulation timestep (dt) rather than simulation time. The > > warning is harmless. The SpikeRingBuffer is a ring-buffer for > > temporarily storing spikes and the size of the buffer is is > > SynChan.bufferTime/dt. So if you make dt small without reducing > > bufferTime, it avoids increasing the number of entries beyond the > > predefined maximum. > > That aside, the HSolve class has not yet been fully ported to > > async13 branch and I encourage you to modify the testHSolve script to > > test this. > > > > Best, > > Subhasis > > > > On 7/2/14, Saeed Shariati <sd....@gm...> wrote: > >> Dear all, > >> > >> In the Demo/snippents/testHSolve.py file, when the simulation time > >> increases (for example 0.1 instead of 0.01), application exits with the > >> below error: > >> > >> *Warning: SpikeRingBuffer: bin number exceeds limit: spikeTime = > 0.047002, > >> currtime= 0, dt = 0.0001, bin = 470 >= 128, terminating* > >> *python: SpikeRingBuffer.cpp:63: void SpikeRingBuffer::addSpike(double, > >> double): Assertion `0' failed.* > >> > >> I've compiled with BUILD=debug. > >> Any clue would be appreciated. > >> > >> Thank you, > >> Saeed > >> > ------------------------------------------------------------------------------ > >> Open source business process management suite built on Java and Eclipse > >> Turn processes into business applications with Bonita BPM Community > Edition > >> Quickly connect people, data, and systems into organized workflows > >> Winner of BOSSIE, CODIE, OW2 and Gartner awards > >> http://p.sf.net/sfu/Bonitasoft > >> _______________________________________________ > >> moose-devel mailing list > >> moo...@li... > >> https://lists.sourceforge.net/lists/listinfo/moose-devel > >> > > > > > ------------------------------------------------------------------------------ > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > _______________________________________________ > moose-devel mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moose-devel > |
From: saeed <sa...@gn...> - 2014-07-03 23:39:23
|
Dear Subhasis, Application crashes with Assertion failure in SpikeRingBuffer.cpp:63 and actually I just put the warning to maybe guide to the problem. My change is not about the dt, after just a little increase in simulation time (from 0.01 to 0.1) I see this problem. I am wondering, maybe SynChan is not working properly. I know that the HSolve is still under control, but in other side I finished the GPU implementation and for accuracy test, I need to make the Moose work. It would be my great pleasure if you direct the issue to the responsible developer. Thank you in advance. Saeed On 02-07-2014 15:25, Subhasis Ray wrote: > Dear Saeed, > You mean simulation timestep (dt) rather than simulation time. The > warning is harmless. The SpikeRingBuffer is a ring-buffer for > temporarily storing spikes and the size of the buffer is is > SynChan.bufferTime/dt. So if you make dt small without reducing > bufferTime, it avoids increasing the number of entries beyond the > predefined maximum. > That aside, the HSolve class has not yet been fully ported to > async13 branch and I encourage you to modify the testHSolve script to > test this. > > Best, > Subhasis > > On 7/2/14, Saeed Shariati <sd....@gm...> wrote: >> Dear all, >> >> In the Demo/snippents/testHSolve.py file, when the simulation time >> increases (for example 0.1 instead of 0.01), application exits with the >> below error: >> >> *Warning: SpikeRingBuffer: bin number exceeds limit: spikeTime = 0.047002, >> currtime= 0, dt = 0.0001, bin = 470 >= 128, terminating* >> *python: SpikeRingBuffer.cpp:63: void SpikeRingBuffer::addSpike(double, >> double): Assertion `0' failed.* >> >> I've compiled with BUILD=debug. >> Any clue would be appreciated. >> >> Thank you, >> Saeed >> ------------------------------------------------------------------------------ >> Open source business process management suite built on Java and Eclipse >> Turn processes into business applications with Bonita BPM Community Edition >> Quickly connect people, data, and systems into organized workflows >> Winner of BOSSIE, CODIE, OW2 and Gartner awards >> http://p.sf.net/sfu/Bonitasoft >> _______________________________________________ >> moose-devel mailing list >> moo...@li... >> https://lists.sourceforge.net/lists/listinfo/moose-devel >> > |
From: Subhasis R. <ray...@gm...> - 2014-07-02 18:25:49
|
Dear Saeed, You mean simulation timestep (dt) rather than simulation time. The warning is harmless. The SpikeRingBuffer is a ring-buffer for temporarily storing spikes and the size of the buffer is is SynChan.bufferTime/dt. So if you make dt small without reducing bufferTime, it avoids increasing the number of entries beyond the predefined maximum. That aside, the HSolve class has not yet been fully ported to async13 branch and I encourage you to modify the testHSolve script to test this. Best, Subhasis On 7/2/14, Saeed Shariati <sd....@gm...> wrote: > Dear all, > > In the Demo/snippents/testHSolve.py file, when the simulation time > increases (for example 0.1 instead of 0.01), application exits with the > below error: > > *Warning: SpikeRingBuffer: bin number exceeds limit: spikeTime = 0.047002, > currtime= 0, dt = 0.0001, bin = 470 >= 128, terminating* > *python: SpikeRingBuffer.cpp:63: void SpikeRingBuffer::addSpike(double, > double): Assertion `0' failed.* > > I've compiled with BUILD=debug. > Any clue would be appreciated. > > Thank you, > Saeed > ------------------------------------------------------------------------------ > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > _______________________________________________ > moose-devel mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moose-devel > -- Best, - Subhasis ( ʃʊbʱaːʃɪʃ ) |
From: Saeed S. <sd....@gm...> - 2014-07-02 16:27:07
|
Dear all, In the Demo/snippents/testHSolve.py file, when the simulation time increases (for example 0.1 instead of 0.01), application exits with the below error: *Warning: SpikeRingBuffer: bin number exceeds limit: spikeTime = 0.047002, currtime= 0, dt = 0.0001, bin = 470 >= 128, terminating* *python: SpikeRingBuffer.cpp:63: void SpikeRingBuffer::addSpike(double, double): Assertion `0' failed.* I've compiled with BUILD=debug. Any clue would be appreciated. Thank you, Saeed |
From: Saeed S. <sa...@gn...> - 2014-06-03 15:00:47
|
Dear Upi I will look at snippets and if I could not sovle the issue, I will ask with details. Thank you for your time. Saeed On 06/03/2014 11:47 AM, U.S.Bhalla wrote: > Dear Saeed, > Please look at the snippets regarding message passing. This is used > when during runtime you need to send data to one ore more objects. I > stress that this should NOT be used for sending data to the Python shell. > > It might help for you to write some pseudocode to indicate what it is > you are trying to do, and why. > > Best, > Upi > > On Tuesday 03 June 2014 08:05 PM, Saeed Shariati wrote: >> Dear Upi, >> >> In low level. I am developing a MasterHSolve to replace with the current >> HSolve and deals with batch of neurons for GPU+CPU. >> >> I tried to send data to the Shell for generating output, but my sending >> does not affect the output. My question is: Does the Shell keep an >> internal presentation for each object and for input we should change it? >> and what is the best method if a solver wants to generate output? (I >> mean standard outputs same as Table object) >> >> Thanks, >> Saeed >> >> On 06/03/2014 01:43 AM, U.S.Bhalla wrote: >>> Dear Saeed, >>> Unclear what you wish to do. There is a set of access functions >>> from Python to retrieve field values. For a compartment on >>> '/model/compt' you would do >>> >>> x = moose.element( '/model/compt' ) >>> print x.Vm >>> >>> if you want to access the value from the Python shell. The snippets in >>> Demos/snippets have many examples. >>> >>> If on the other hand you want to do a low-level transfer of information >>> between MOOSE objects, you can use the message sending mechanism below, >>> but the data will only go to objects which have been connected up >>> through message creation functions. There are examples of this also in >>> the snippets. >>> >>> Best, >>> Upi >>> >>> On Tuesday 03 June 2014 09:35 AM, Saeed Shariati wrote: >>>> Dear all, >>>> >>>> I'm trying to send Vm to the shell and according to the HSolve >>>> implementation, the value sets via the below mechanism: >>>> >>>> moose::Compartment::VmOut()->send(compartmentId.eref(), newVm); >>>> >>>> In the first glance, I thought that just by calling this method, in any >>>> place, we can change internal representation of Vm in the Shell and the >>>> output mechanism can read it via clock mechanim. >>>> >>>> But, for example when I send an specific value via this message, there is >>>> no change in the output in Python. Would you please guide me about the I/O >>>> mechanism in shell and also that command is the only thing that provides >>>> output? >>>> >>>> Thank you, >>>> Saeed >>>> ------------------------------------------------------------------------------ >>>> Learn Graph Databases - Download FREE O'Reilly Book >>>> "Graph Databases" is the definitive new guide to graph databases and their >>>> applications. Written by three acclaimed leaders in the field, >>>> this first edition is now available. Download your free book today! >>>> http://p.sf.net/sfu/NeoTech >>>> _______________________________________________ >>>> moose-devel mailing list >>>> moo...@li... >>>> https://lists.sourceforge.net/lists/listinfo/moose-devel >>> ------------------------------------------------------------------------------ >>> Learn Graph Databases - Download FREE O'Reilly Book >>> "Graph Databases" is the definitive new guide to graph databases and their >>> applications. Written by three acclaimed leaders in the field, >>> this first edition is now available. Download your free book today! >>> http://p.sf.net/sfu/NeoTech >>> _______________________________________________ >>> moose-devel mailing list >>> moo...@li... >>> https://lists.sourceforge.net/lists/listinfo/moose-devel >>> >>> >> ------------------------------------------------------------------------------ >> Learn Graph Databases - Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and their >> applications. Written by three acclaimed leaders in the field, >> this first edition is now available. Download your free book today! >> http://p.sf.net/sfu/NeoTech >> _______________________________________________ >> moose-devel mailing list >> moo...@li... >> https://lists.sourceforge.net/lists/listinfo/moose-devel > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/NeoTech > _______________________________________________ > moose-devel mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moose-devel > > |
From: U.S.Bhalla <bh...@nc...> - 2014-06-03 14:47:53
|
Dear Saeed, Please look at the snippets regarding message passing. This is used when during runtime you need to send data to one ore more objects. I stress that this should NOT be used for sending data to the Python shell. It might help for you to write some pseudocode to indicate what it is you are trying to do, and why. Best, Upi On Tuesday 03 June 2014 08:05 PM, Saeed Shariati wrote: > Dear Upi, > > In low level. I am developing a MasterHSolve to replace with the current > HSolve and deals with batch of neurons for GPU+CPU. > > I tried to send data to the Shell for generating output, but my sending > does not affect the output. My question is: Does the Shell keep an > internal presentation for each object and for input we should change it? > and what is the best method if a solver wants to generate output? (I > mean standard outputs same as Table object) > > Thanks, > Saeed > > On 06/03/2014 01:43 AM, U.S.Bhalla wrote: >> Dear Saeed, >> Unclear what you wish to do. There is a set of access functions >> from Python to retrieve field values. For a compartment on >> '/model/compt' you would do >> >> x = moose.element( '/model/compt' ) >> print x.Vm >> >> if you want to access the value from the Python shell. The snippets in >> Demos/snippets have many examples. >> >> If on the other hand you want to do a low-level transfer of information >> between MOOSE objects, you can use the message sending mechanism below, >> but the data will only go to objects which have been connected up >> through message creation functions. There are examples of this also in >> the snippets. >> >> Best, >> Upi >> >> On Tuesday 03 June 2014 09:35 AM, Saeed Shariati wrote: >>> Dear all, >>> >>> I'm trying to send Vm to the shell and according to the HSolve >>> implementation, the value sets via the below mechanism: >>> >>> moose::Compartment::VmOut()->send(compartmentId.eref(), newVm); >>> >>> In the first glance, I thought that just by calling this method, in any >>> place, we can change internal representation of Vm in the Shell and the >>> output mechanism can read it via clock mechanim. >>> >>> But, for example when I send an specific value via this message, there is >>> no change in the output in Python. Would you please guide me about the I/O >>> mechanism in shell and also that command is the only thing that provides >>> output? >>> >>> Thank you, >>> Saeed >>> ------------------------------------------------------------------------------ >>> Learn Graph Databases - Download FREE O'Reilly Book >>> "Graph Databases" is the definitive new guide to graph databases and their >>> applications. Written by three acclaimed leaders in the field, >>> this first edition is now available. Download your free book today! >>> http://p.sf.net/sfu/NeoTech >>> _______________________________________________ >>> moose-devel mailing list >>> moo...@li... >>> https://lists.sourceforge.net/lists/listinfo/moose-devel >> ------------------------------------------------------------------------------ >> Learn Graph Databases - Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and their >> applications. Written by three acclaimed leaders in the field, >> this first edition is now available. Download your free book today! >> http://p.sf.net/sfu/NeoTech >> _______________________________________________ >> moose-devel mailing list >> moo...@li... >> https://lists.sourceforge.net/lists/listinfo/moose-devel >> >> > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/NeoTech > _______________________________________________ > moose-devel mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moose-devel |
From: Saeed S. <sa...@gn...> - 2014-06-03 14:37:29
|
Dear Upi, In low level. I am developing a MasterHSolve to replace with the current HSolve and deals with batch of neurons for GPU+CPU. I tried to send data to the Shell for generating output, but my sending does not affect the output. My question is: Does the Shell keep an internal presentation for each object and for input we should change it? and what is the best method if a solver wants to generate output? (I mean standard outputs same as Table object) Thanks, Saeed On 06/03/2014 01:43 AM, U.S.Bhalla wrote: > Dear Saeed, > Unclear what you wish to do. There is a set of access functions > from Python to retrieve field values. For a compartment on > '/model/compt' you would do > > x = moose.element( '/model/compt' ) > print x.Vm > > if you want to access the value from the Python shell. The snippets in > Demos/snippets have many examples. > > If on the other hand you want to do a low-level transfer of information > between MOOSE objects, you can use the message sending mechanism below, > but the data will only go to objects which have been connected up > through message creation functions. There are examples of this also in > the snippets. > > Best, > Upi > > On Tuesday 03 June 2014 09:35 AM, Saeed Shariati wrote: >> Dear all, >> >> I'm trying to send Vm to the shell and according to the HSolve >> implementation, the value sets via the below mechanism: >> >> moose::Compartment::VmOut()->send(compartmentId.eref(), newVm); >> >> In the first glance, I thought that just by calling this method, in any >> place, we can change internal representation of Vm in the Shell and the >> output mechanism can read it via clock mechanim. >> >> But, for example when I send an specific value via this message, there is >> no change in the output in Python. Would you please guide me about the I/O >> mechanism in shell and also that command is the only thing that provides >> output? >> >> Thank you, >> Saeed >> ------------------------------------------------------------------------------ >> Learn Graph Databases - Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and their >> applications. Written by three acclaimed leaders in the field, >> this first edition is now available. Download your free book today! >> http://p.sf.net/sfu/NeoTech >> _______________________________________________ >> moose-devel mailing list >> moo...@li... >> https://lists.sourceforge.net/lists/listinfo/moose-devel > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/NeoTech > _______________________________________________ > moose-devel mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moose-devel > > |
From: U.S.Bhalla <bh...@nc...> - 2014-06-03 04:43:33
|
Dear Saeed, Unclear what you wish to do. There is a set of access functions from Python to retrieve field values. For a compartment on '/model/compt' you would do x = moose.element( '/model/compt' ) print x.Vm if you want to access the value from the Python shell. The snippets in Demos/snippets have many examples. If on the other hand you want to do a low-level transfer of information between MOOSE objects, you can use the message sending mechanism below, but the data will only go to objects which have been connected up through message creation functions. There are examples of this also in the snippets. Best, Upi On Tuesday 03 June 2014 09:35 AM, Saeed Shariati wrote: > Dear all, > > I'm trying to send Vm to the shell and according to the HSolve > implementation, the value sets via the below mechanism: > > moose::Compartment::VmOut()->send(compartmentId.eref(), newVm); > > In the first glance, I thought that just by calling this method, in any > place, we can change internal representation of Vm in the Shell and the > output mechanism can read it via clock mechanim. > > But, for example when I send an specific value via this message, there is > no change in the output in Python. Would you please guide me about the I/O > mechanism in shell and also that command is the only thing that provides > output? > > Thank you, > Saeed > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/NeoTech > _______________________________________________ > moose-devel mailing list > moo...@li... > https://lists.sourceforge.net/lists/listinfo/moose-devel |
From: Saeed S. <sa...@gn...> - 2014-06-03 04:05:51
|
Dear all, I'm trying to send Vm to the shell and according to the HSolve implementation, the value sets via the below mechanism: moose::Compartment::VmOut()->send(compartmentId.eref(), newVm); In the first glance, I thought that just by calling this method, in any place, we can change internal representation of Vm in the Shell and the output mechanism can read it via clock mechanim. But, for example when I send an specific value via this message, there is no change in the output in Python. Would you please guide me about the I/O mechanism in shell and also that command is the only thing that provides output? Thank you, Saeed |
From: Subhasis R. <ray...@gm...> - 2014-05-05 06:47:07
|
Dear Misha, On Sat, May 3, 2014 at 10:40 PM, Subhasis Ray <ray...@gm...>wrote: > > On Sat, May 3, 2014 at 9:15 PM, Misha Ahmadian <mis...@tt...>wrote: > >> results, but the problem is the recurrentIntFire.py file. This file in the >> async13/tests/python/mpi could be running, but without any termination and >> real MPI working. we run this part as bellow: >> >> but still we cannot get any result from this model. Would you please let >> me >> know, if we can have the correct recurrentIntFire.py, to produce our >> results. It would be highly appreciated if you help us as soon as >> possible. >> > > This seems to be system dependent issue and I am also encountering it > while others are not. > > ... > > If it is stuck after that, that is the command prompt of MOOSE expecting > user input - I cannot tell right away why it is acting like that, but we'll > try to address that ASAP. > > Looks like the problem is solved on your side: http://sourceforge.net/p/moose/mailman/message/32298540/ Just for the record, this kind of situation can happen (1) when mpich2 and openmpi are simultaneously present on the same system and you need to get mpich2 out of the way (2) the default build does not use mpi now (it used to earlier), so you have to explicitly build with USE_MPI=1 or BUILD=mpi or BUILD=ompi option. mpi will not stop you from running a non-mpi program using mpirun and in that case after the main process quits, other instances of moose will be waiting for commands. Best, - Subhasis ( ʃʊbʱaːʃɪʃ ) |