moose-generic — Moose general discussions

[moose-generic] Problem_to_install_Moose_on_cluster

[vadim a. <vad...@ho...>]

Dear MOOSE team
I am trying to build and install MOOSE on
CentOS release 5.5 (Final)x86_64 x86_64 x86_64 GNU/Linux
BUILD step finished with a few warnings but no error and it seems that "All Libs compiled" but "No rule to make target 'biophysics/_biophysics.0' needed by 'moose'.Stop'


../basecode/Conv.h:1009: warning: converting to 'unsigned int' from 'const double'g++ -O3 -pthread -fpermissive -fno-strict-aliasing -fPIC -Wall -Wno-long-long -pedantic -DNDEBUG -DUSE_GENESIS_PARSER -DSVN_REVISION=\"4401\" -DLINUX -DUSE_GSL -DUSE_HDF5  -DH5_NO_DEPRECATED_SYMBOLS -I/usr/local/hdf5/include  -I.. -I../basecode testSigNeur.cpp -cld -r -o _signeur.o Adaptor.o testSigNeur.o     make[1]: Leaving directory `/home/astakhov/moose/moose/signeur'All Libs compiledmake: *** No rule to make target `biophysics/_biophysics.o', needed by `moose'.  Stop.




After that I am running "make install" but getting error
make: python-config: Command not foundmake: python-config: Command not found## discard symbols from object filesstrip python/moose/_moose.sostrip: 'python/moose/_moose.so': No such filemake: *** [install] Error 1



Can somebody advise what is the problem ?
Thanks a lot in advance.
Vadim.
 		 	   		  

Re: [moose-generic] Subversion URL changed

[Alexander K. <ak...@na...>]

Is there a ftp mirror of the source tree or just plain tarballs of 
the releases and nightly snapshots?

Alex.

[moose-generic] Subversion URL changed

[Niraj D. <ni...@nc...>]

Hello all,

This message is for anyone who uses the MOOSE subversion repository to stay updated with
the latest MOOSE code. The URL for the subversion repository has recently changed to:
    svn://svn.code.sf.net/p/moose/code/moose/branches/buildQ

You can perform a fresh checkout using this command:
    svn checkout svn://svn.code.sf.net/p/moose/code/moose/branches/buildQ

(Note: One can usually use the 'svn switch' command to re-base your working copy to a
new URL, but since the protocol has changed from HTTP to SVN, this does not seem to
work.)

Best,
Niraj

Re: [moose-generic] shape of the compartment

[Niraj D. <ni...@nc...>]

Dear Ekaterina,

Your email to the list had got stuck in the list's filter.

As I mentioned earlier (in person), the length and diameter do not hold much numerical
importance. They are mainly there to hold structural information, that can be used for
displaying the cell. When one reads in a model (NeuroML or ReadCell), the import code
usually assumes cylindrical compartments, and calculates the passive parameters
accordingly. However, you are free to change the Ra, Rm and Cm yourself afterwards. The
numerical implementations (EE and HSolve) do not care about the length/diameter, and
instead just look at the Ra, Rm and Cm values for each compartment.

Best,
Niraj


> Dear All,
>
> could you make it clear regarding the shape of the compartment ?
> For example, if I want to create a rectangular shape and then I set length
> and diameter fields. How then other parameters (for instance Ra) will be
> recalculated?
> Or, shall I calculate the values by myself and then set the parameters
> manually according to my shape? If it's so, will that work correctly during
> the simulation, I mean where else the shape of the compartment can be used?
>
> P.S. I'm using buildQ branch.
>
> thank you
> kind regards,
> Katja
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnnow-d2d_______________________________________________
> moose-generic mailing list
> moo...@li...
> https://lists.sourceforge.net/lists/listinfo/moose-generic
>

Re: [moose-generic] input and output messages for the HHChannel

[Niraj D. <ni...@nc...>]

Hi again, Katja,

You've asked the following 3 questions:

> 1. I'm trying to get information about input and output messages for the
> HHChannel object (...)


> 2. I've set up two HHGates (X and Y) for HHChannel,
> however when I try to print the output messages for a channel it reports
> me 3 output messages (...)


> 3. When I try to print input messages for a channel it reports me:
> /model/soma /model/soma/Na_channel
> /model/soma /model/soma/Na_channel


I'll first try to address questions 1 and 3:
  - Can you tell me why you're trying to find the input and output messages?
    It will help me answer your questions better.
  - If you just want to explore the model structure, then what you're
doing in
    (1) is correct. Even simpler is to use the moose.showmsg() function.
    However, I am getting the same errors that you have reported. I will see
    if Subhasis can tackle this.
  - An alternative to the above methods is using the 'neighbours' dictionary.
    For example, to find all the channels connected to a compartment, just
do:
        soma.neighbours[ 'channel' ]
    This gives you a tuple of all the objects connected to 'soma' via the
    'channel' Finfo.
  - You may be right that the "VmOut -> Vm" message has already been setup
    automatically before.

    The correct way to connect a compartment and a channel is:
        moose.connect(soma, 'channel', Na_channel, 'channel')
    'channel' is a shared message which will allow a Compartment to send
Vm to
    channels, but also receive current back (in the form of Gk, Ek). If your
    compartment and channel are already connected via the 'channel' finfos,
    then you don't need to make the "VmOut -> Vm" connection. You can check
    if the "channel" message has already been setup by using the
    "soma.neighbours[ 'channel' ]" example given above.

    I am not sure if you are building your model by hand (by creating
    'Compartment' and 'HHChannel' objects manually, and connecting them using
    moose.connect()), or if you're loading in a model using, say, the NeuroML
    reader. In the case of loading in models, the "channel" message is
already
    set up for you.

  - If you're interested in looking at all the fields/finfos of a
class/object,
    you can do:
        hh = moose.HHChannel( '/hh' )
        moose.doc( hh )
    or simply:
        moose.doc( moose.HHChannel )

    The documentation for all MOOSE classes and functions is compiled and
    available here:
        http://moose.ncbs.res.in/component/option,com_wrapper/Itemid,94/

    You will find the same file in your 'moose/Docs/user' folder as well.

Regarding question 2, this is expected behaviour. All the 3 gates (X, Y, Z)
are made immediately in a dummy form when a channel is created. Only when you
set the Xpower, Ypower or Zpower, the gates are actually created.

Do let us know if there are any other problems.

Best,
Niraj

Re: [moose-generic] HSolve usage

[Niraj D. <ni...@nc...>]

Dear Katja,

I'm looking at what the problem might be. In the meantime, can you send me
your script?

Thanks,
Niraj

> Dear Niraj,
>
> the reason why I asked was that if I replace
> moose.useClock(0, '/model/##', 'process')
> with
>  solver = moose.HSolve('/model/solve')
>  solver.dt = moose.element('/clock/tick[0]').dt
>  solver.target = '/model/' #I've tried also solver.target = '/model/##'
>  moose.useClock(0,'/model/solve', 'process')
>
> then a simulation stopped working - I have a horizontal line instead of
> firing behavior...
>
>
>
>
> 2013/1/11 Niraj Dudani <ni...@nc...>
>
>> Hi Katja,
>>
>> > solver = moose.HSolve('/model/solve')
>> > solver.dt = moose.element('/clock/tick[0]').dt
>> > solver.target = '/model/'
>> > moose.useClock(0,'/model/solve', 'process')
>> >
>> > instead of:
>> > moose.useClock(0, '/model/##', 'process')
>> >
>> > does it look correct?
>>
>> This is perfect.
>>
>> Scheduling and solver setup is one thing that always leaves the doubt
>> of:
>> "Am I doing this right?". For this reason, Aditya has already written a
>> utility function (moose.utils.resetSim()) to make scheduling of
>> biophysical objects easier. You may not need this, because you are only
>> scheduling the HSolve, and not Compartment, HHChannel, etc. We may even
>> look at resurrecting autoscheduling so that moose.useClock() is not
>> needed
>> at all. Finally, I plan to upgrade Aditya's resetSim() function to
>> handle
>> solver set up as well.
>>
>> For now, what you've done seems correct. Do let us know if you run into
>> problems.
>>
>> Best,
>> Niraj
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
>> much more. Get web development skills now with LearnDevNow -
>> 350+ hours of step-by-step video tutorials by Microsoft MVPs and
>> experts.
>> SALE $99.99 this month only -- learn more at:
>> http://p.sf.net/sfu/learnmore_122812
>> _______________________________________________
>> moose-generic mailing list
>> moo...@li...
>> https://lists.sourceforge.net/lists/listinfo/moose-generic
>>
>

Re: [moose-generic] HSolve usage

[Ekaterina B. <de....@gm...>]

Dear Niraj,

the reason why I asked was that if I replace
moose.useClock(0, '/model/##', 'process')
with
 solver = moose.HSolve('/model/solve')
 solver.dt = moose.element('/clock/tick[0]').dt
 solver.target = '/model/' #I've tried also solver.target = '/model/##'
 moose.useClock(0,'/model/solve', 'process')

then a simulation stopped working - I have a horizontal line instead of
firing behavior...




2013/1/11 Niraj Dudani <ni...@nc...>

> Hi Katja,
>
> > solver = moose.HSolve('/model/solve')
> > solver.dt = moose.element('/clock/tick[0]').dt
> > solver.target = '/model/'
> > moose.useClock(0,'/model/solve', 'process')
> >
> > instead of:
> > moose.useClock(0, '/model/##', 'process')
> >
> > does it look correct?
>
> This is perfect.
>
> Scheduling and solver setup is one thing that always leaves the doubt of:
> "Am I doing this right?". For this reason, Aditya has already written a
> utility function (moose.utils.resetSim()) to make scheduling of
> biophysical objects easier. You may not need this, because you are only
> scheduling the HSolve, and not Compartment, HHChannel, etc. We may even
> look at resurrecting autoscheduling so that moose.useClock() is not needed
> at all. Finally, I plan to upgrade Aditya's resetSim() function to handle
> solver set up as well.
>
> For now, what you've done seems correct. Do let us know if you run into
> problems.
>
> Best,
> Niraj
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
> much more. Get web development skills now with LearnDevNow -
> 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
> SALE $99.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122812
> _______________________________________________
> moose-generic mailing list
> moo...@li...
> https://lists.sourceforge.net/lists/listinfo/moose-generic
>

Re: [moose-generic] HSolve usage

[Niraj D. <ni...@nc...>]

Hi Katja,

> solver = moose.HSolve('/model/solve')
> solver.dt = moose.element('/clock/tick[0]').dt
> solver.target = '/model/'
> moose.useClock(0,'/model/solve', 'process')
>
> instead of:
> moose.useClock(0, '/model/##', 'process')
>
> does it look correct?

This is perfect.

Scheduling and solver setup is one thing that always leaves the doubt of:
"Am I doing this right?". For this reason, Aditya has already written a
utility function (moose.utils.resetSim()) to make scheduling of
biophysical objects easier. You may not need this, because you are only
scheduling the HSolve, and not Compartment, HHChannel, etc. We may even
look at resurrecting autoscheduling so that moose.useClock() is not needed
at all. Finally, I plan to upgrade Aditya's resetSim() function to handle
solver set up as well.

For now, what you've done seems correct. Do let us know if you run into
problems.

Best,
Niraj

Re: [moose-generic] input and output messages for the HHChannel

[Niraj D. <ni...@nc...>]

Hi Katja,

Thanks for your questions. Have noted them, and will reply very soon.

Best,
Niraj

> Dear All,
>
> Basically I have 3 questions:
> 1.
> I'm trying to get information about input and output messages for the
> HHChannel object, for example:
> for m in Na_ch.msgOut:
>      print m.e1.path, m.e2.path, m.srcFieldsOnE1, m.destFieldsOnE2
>
> But it seem like smth is not supported yet?
> /model/soma /model/soma/Na_channelError: Cinfo::srcFinfoName( 0 ): not
> found
> Error: Msg::getSrcFieldsOnE1: Failed to find field on msg
> soma-->Na_channel
>  ()Error: Cinfo::destFinfoName( 0 ): not found
> Error: Msg::getDestFieldsOnE2: Failed to find field on msg
> soma-->Na_channel
>  ()
>
> or I do smth wrong?
>
> 2. I've set up two HHGates (X and Y) for HHChannel,
> however when I try to print the output messages for a channel it reports
> me
> 3 output messages:
>
> /model/soma/Na_channel /model/soma/Na_channel/gateX[0]
> /model/soma/Na_channel /model/soma/Na_channel/gateY[0]
> /model/soma/Na_channel /model/soma/Na_channel/gateZ[0]
>
> It's a little bit confusing..Shall it be like this?
>
> 3. When I try to print input messages for a channel it reports me:
> /model/soma /model/soma/Na_channel
> /model/soma /model/soma/Na_channel
> To my regret I don't know how to look at the source/destFinfoNames,
> probably it's too different messages. However, I set up only one message
> between these two elements:
> c_soma_NaChannel = moose.connect(soma, 'VmOut', Na_channel, 'Vm')
> probably this message is set up automatically and by setting it up it's
> set
> up twice? :)
>
> thank you,
> kind regards,
> Katja
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122712_______________________________________________
> moose-generic mailing list
> moo...@li...
> https://lists.sourceforge.net/lists/listinfo/moose-generic
>

[moose-generic] input and output messages for the HHChannel

[Ekaterina B. <de....@gm...>]

Dear All,

Basically I have 3 questions:
1.
I'm trying to get information about input and output messages for the
HHChannel object, for example:
for m in Na_ch.msgOut:
     print m.e1.path, m.e2.path, m.srcFieldsOnE1, m.destFieldsOnE2

But it seem like smth is not supported yet?
/model/soma /model/soma/Na_channelError: Cinfo::srcFinfoName( 0 ): not found
Error: Msg::getSrcFieldsOnE1: Failed to find field on msg soma-->Na_channel
 ()Error: Cinfo::destFinfoName( 0 ): not found
Error: Msg::getDestFieldsOnE2: Failed to find field on msg soma-->Na_channel
 ()

or I do smth wrong?

2. I've set up two HHGates (X and Y) for HHChannel,
however when I try to print the output messages for a channel it reports me
3 output messages:

/model/soma/Na_channel /model/soma/Na_channel/gateX[0]
/model/soma/Na_channel /model/soma/Na_channel/gateY[0]
/model/soma/Na_channel /model/soma/Na_channel/gateZ[0]

It's a little bit confusing..Shall it be like this?

3. When I try to print input messages for a channel it reports me:
/model/soma /model/soma/Na_channel
/model/soma /model/soma/Na_channel
To my regret I don't know how to look at the source/destFinfoNames,
probably it's too different messages. However, I set up only one message
between these two elements:
c_soma_NaChannel = moose.connect(soma, 'VmOut', Na_channel, 'Vm')
probably this message is set up automatically and by setting it up it's set
up twice? :)

thank you,
kind regards,
Katja

[moose-generic] HSolve usage

[Ekaterina B. <de....@gm...>]

Dear All,

how to setup and use HSolve correctly?

I do smth like:
solver = moose.HSolve('/model/solve')
solver.dt = moose.element('/clock/tick[0]').dt
solver.target = '/model/'
moose.useClock(0,'/model/solve', 'process')

instead of:
moose.useClock(0, '/model/##', 'process')

does it look correct?

thank you,
kind regards,
Katja

[moose-generic] shape of the compartment

[Ekaterina B. <de....@gm...>]

Dear All,

could you make it clear regarding the shape of the compartment ?
For example, if I want to create a rectangular shape and then I set length
and diameter fields. How then other parameters (for instance Ra) will be
recalculated?
Or, shall I calculate the values by myself and then set the parameters
manually according to my shape? If it's so, will that work correctly during
the simulation, I mean where else the shape of the compartment can be used?

P.S. I'm using buildQ branch.

thank you
kind regards,
Katja

Re: [moose-generic] Installing moose with fenics

[Aditya G. <adi...@ya...>]

Dear Chaitanya,

Subhasis and I looked at this issue.
Moose debian package is linked against libhdf5-serial-1.8.4 .
Apparently fenics requires libhdf5-openmpi-1.8.4 which conflicts with libhdf5-serial-1.8.4.


Releasing a deb package linked against the openmpi version will require openmpi dependencies etc. for moose which are not relevant.

Presently, your best course will be to uninstall moose, install fenics, then compile and install moose from source. Subha expects that moose should compile against the openmpi version of libhdf5. You'll need libhdf5-openmpi-dev installed. Mostly make and make install should work fine, if the names of libraries, headers etc are same across the serial and openmpi versions.

There is another libhdf5 issue that Alex reported, but that seems to be different from yours.

Let us know how the source compile goes.

Cheers,
Aditya.




>________________________________
> From: Chaitanya <cc...@gm...>
>To: moo...@li... 
>Sent: Thursday, 29 November 2012 4:17 AM
>Subject: [moose-generic] Installing moose with fenics
> 
>
>Hi guys,
>
>I am using moose 2.0.0 python 2.7 debian 32 bit version. I installed this on a new machine (Ubuntu 12.04)
>
>I do this via ubuntu software manager (basically click the above deb). And in resolving the dependencies, it removes fenics (http://fenicsproject.org/) without any warning. 
>
>When I try to reinstall fenics via synaptic, it demands me to remove the following packages as they are in conflict.
>
>libhdf5-serial-1.8.4
>libhdf5-serial-dev
>moose 
>
>How do I proceed?
>
>Cheers!
>Chaitanya
>
>------------------------------------------------------------------------------
>Keep yourself connected to Go Parallel: 
>INSIGHTS What's next for parallel hardware, programming and related areas?
>Interviews and blogs by thought leaders keep you ahead of the curve.
>http://goparallel.sourceforge.net
>_______________________________________________
>moose-generic mailing list
>moo...@li...
>https://lists.sourceforge.net/lists/listinfo/moose-generic
>
>
>

[moose-generic] Installing moose with fenics

[Chaitanya <cc...@gm...>]

Hi guys,

I am using moose 2.0.0 python 2.7 debian 32 bit version. I installed this
on a new machine (Ubuntu 12.04)

I do this via ubuntu software manager (basically click the above deb). And
in resolving the dependencies, it removes fenics (http://fenicsproject.org/)
without any warning.

When I try to reinstall fenics via synaptic, it demands me to remove the
following packages as they are in conflict.

libhdf5-serial-1.8.4
libhdf5-serial-dev
moose

How do I proceed?

Cheers!
Chaitanya

Re: [moose-generic] hdf5 version, etc.

[Alexander K. <ak...@na...>]

Hi Subha,

thanks for your explanations!

>> 3) help(moose) crashes with 'Segmentation fault' message
>>     help(moose.connect) and moose.doc(moose.Compartment) work fine
>>
> [...]
> The only solution I could find till now makes it impossible to use "from
> moose import *" and use the MOOSE classes. This is very common practice in
> spite of being frowned upon by the Python style guides. So we need more
> work to track it down.

Yes, this works:

from moose import *
help(moose)
help(moose.connect)
moose.doc(moose.Compartment)

>> This is after creating link libhdf5.so.6->libhdf5.so; same happens
>> on another machine which runs source-build moose and doesn't need
>> that workaround.
>>
>
> Is that a release or a debug build?

The default, i.e. 'release'. Here is my build script (where PKG is 
a stage directory):

build()
{
   sed -i -e 's/pymoose: CXX.*/& -I$(shell python -c "import numpy; print numpy.get_include()")/' \
     -e 's/.*HOME.*/#&/' \
     -e 's/.*update-icon-caches.*/#&/' \
     Makefile
   make SVN=0 || exit
   make DESTDIR=$PKG install || exit
   rm -v $PKG/usr/bin/moosegui
   ln -sv ../share/moose/gui/MooseGUI.py $PKG/usr/bin/moosegui
   rm -rv $PKG/usr/share/{applications,doc,moose/Demos}
}

Regards,
Alex.

Re: [moose-generic] hdf5 version, etc.

[Subhasis R. <ray...@gm...>]

Hi Alex,
 Thank you for reporting the issues. I think Niraj' response did not go to
the mailing list. So I'll put it on record and add my input regarding the
bugs.

On Tue, Nov 20, 2012 at 10:47 PM, Alexander Kozlov <ak...@na...>wrote:

> 1) Moose in the Debian package 'moose_2.0.0_i386_python2.7.deb'
> is built against libhdf5.so.6 (not libhdf5.so) and can't work
> in the current Debian 'sid' environment which installs
> libhdf5.so.7
>
> 2) Link to release notes on NCBS server doesn't work
> http://moose.sourceforge.net/downloads/RELEASE_NOTES_MOOSE_2.0.0.html
>

This has been fixed now. The correct link should have been:
http://moose.sourceforge.net/downloads/RELEASE_NOTES_MOOSE_2.0.0.txt


> 3) help(moose) crashes with 'Segmentation fault' message
>     help(moose.connect) and moose.doc(moose.Compartment) work fine
>

This is a bug. Till now I found that it appears only in builds with full
optimization (gcc -O3), e.g., the release build but does not occur in debug
builds (or with release build with "-O3" option removed from the Makefile).
This may be due to some subtle memory leak in the python/C extension. If we
reduce the number of exposed MOOSE classes, then the problem does not
appear. gdb tells us that there is some issue with Python trying to get
some string length.

The only solution I could find till now makes it impossible to use "from
moose import *" and use the MOOSE classes. This is very common practice in
spite of being frowned upon by the Python style guides. So we need more
work to track it down.


> This is after creating link libhdf5.so.6->libhdf5.so; same happens
> on another machine which runs source-build moose and doesn't need
> that workaround.
>

Is that a release or a debug build?

Best,
  Subha

[moose-generic] hdf5 version, etc.

[Alexander K. <ak...@na...>]

1) Moose in the Debian package 'moose_2.0.0_i386_python2.7.deb'
is built against libhdf5.so.6 (not libhdf5.so) and can't work
in the current Debian 'sid' environment which installs 
libhdf5.so.7

2) Link to release notes on NCBS server doesn't work
http://moose.sourceforge.net/downloads/RELEASE_NOTES_MOOSE_2.0.0.html

3) help(moose) crashes with 'Segmentation fault' message
    help(moose.connect) and moose.doc(moose.Compartment) work fine

This is after creating link libhdf5.so.6->libhdf5.so; same happens 
on another machine which runs source-build moose and doesn't need 
that workaround.

/Alex.

[moose-generic] packaging questions

[Alexander K. <ak...@na...>]

Thought I could deposit this discussion here. There is a false 
broken link alarm down there but also few bits that could be 
helpful.

Thanks to the Moose' team for support!
/Alex.



----------------------------------------------------------------
>From ak...@na... Wed Nov  7 09:22:42 2012
Date: Wed, 7 Nov 2012 09:22:42 +0100 (MET)
From: Alexander Kozlov <ak...@na...>
To: Niraj Dudani <ni...@nc...>
Subject: Re: parallel moose?

Hi Niraj,

Best congrats with new release!! This is awesome!

I wonder if any kind of Moose Users Group will be organized? Moose-generic
mailing list seems dead (or can I register and post questions there?)

Before I did, please fix moosegui link in the distribution! It refers to
absolute path to MooseGUI.py on a host machine in the source Makefile, ie
it's broken in binary distribution (amd64 deb, for example).

I build from sources now and plan to test and read up syntax soon so I have
lot of confusion ahead. Excited anyway!

Cheers,
Alex.



>From ad...@nc... Wed Nov  7 10:51:42 2012
Date: Wed, 7 Nov 2012 15:21:08 +0530
From: Aditya Gilra <ad...@nc...>
To: Alexander Kozlov <ak...@na...>
Cc: Niraj Dudani <ni...@nc...>
Subject: Re: parallel moose?

Dear Alex,
Could you give further details below about the broken amd64 package:

1) Did you use python2.6 or python2.7 version of the amd64 packge
that you mention i.e.
moose2.0.0_amd64_python2.6.deb ormoose2.0.0_amd64_python2.7.deb?

2) Are you installing on Ubuntu? Which version? If not, which linux
and which version?

3) Did you install using apt-get / Ubuntu software center or synaptic
or something else?

3) If you type moosegui on a terminal, can you tell me what the error
is (copy and paste the error) ....
On machines that I tested, moosegui links to
/usr/share/moose/gui/MooseGUI.py , so it should have worked.

4) On Ubuntu/Debian, you should also be able to run moosegui from the
mainmenu->Science/Education, or on the latest Ubuntu-s (Unity
interface 11.10 onwards) by typing moose in the dash, and clicking on
the icon for moosegui that appears.

I'd tested all 4 deb packages on their respective systems, so am
surprised by this bug....

Many thanks for the bug-report and for testing MOOSE.

Best,
Aditya.

On Wed, Nov 7, 2012 at 2:58 PM, Niraj Dudani <ni...@nc...>
wrote:
       Hello, Alex, and thanks for your mail and enthusiasm :)

       Feel free to send your questions to the moose-generic
       mailing list! :)
       Yes, it has had no activity, but it has a few subscribers
       already, and all
       of us are already on it. We have mentioned it on the
       MOOSE website, but we
       should really advertise it in the announcement emails as
       well. I'll
       consider sending an email to the comp-neuro mailing list
       announcing that
       this mailing list is functional, and can be used to
       discuss MOOSE issues.
       Thanks for bringing this up.

       Also thanks for the bug report!!! I'm CC'ing it to Aditya
       who has done the
       packaging.

       Regarding getting started with MOOSE syntax, you should
       look at the User
       Documentation section on the MOOSE website:
        http://moose.ncbs.res.in/content/view/5/6/

       You should also look at the 'Demos' directory for more
       examples, and the
       'Demos/snippets' directory for short examples showing
       usage for some basic
       things.

       Best wishes,
       Niraj


>From ak...@na... Wed Nov  7 11:17:39 2012
Date: Wed, 7 Nov 2012 11:17:39 +0100 (MET)
From: Alexander Kozlov <ak...@na...>
To: Aditya Gilra <ad...@nc...>
Cc: Niraj Dudani <ni...@nc...>
Subject: Re: parallel moose?

Hello!

Thank you for your reply.

> 1) Did you use python2.6 or python2.7 version of the amd64 packge that you
> mention i.e.
> moose2.0.0_amd64_python2.6.deb or moose2.0.0_amd64_python2.7.deb?

In the latter file (moose_2.0.0_amd64_python2.7.deb) I got from
http://moose.ncbs.res.in/content/view/35/70/, /usr/bin/moosegui links to
/home/user/moose_src/debian/moose/usr/share/moose/gui/MooseGUI.py

In the source Makefile, moosegui is installed by

ln -s $(DESTDIR)$(install_prefix)/share/moose/gui/MooseGUI.py \
   $(DESTDIR)$(install_prefix)/bin/moosegui

which is plain wrong, I think; particularly, if one makes a stage build for
further packaging. It should be relative instead:

ln -s ../share/moose/gui/MooseGUI.py \
   $(DESTDIR)$(install_prefix)/bin/moosegui

I build Moose from sources so I didn't try binary distribution.
I can do, if you like, I also run Debian on x86 and x86_64 machines.

Thank you again,
Alex.



>From ad...@nc... Wed Nov  7 11:49:18 2012
Date: Wed, 7 Nov 2012 16:18:37 +0530
From: Aditya Gilra <ad...@nc...>
To: Alexander Kozlov <ak...@na...>
Cc: Niraj Dudani <ni...@nc...>
Subject: Re: parallel moose?

Hi Alex,
Thanks for the prompt clarifications.

1) I note that you haven't actually installed the .deb package.
If you do go ahead and install, you'll find that the postinst script
creates a new /usr/bin/moosegui link that overwrites the previous one
and points to the correct location.

Thus, there is no functional bug as I explain in point 2 below, but
your method is simpler... It will eliminate the need for the above
extra link line in the postinst script, since the path is relative.

2) The Makefile line:

ln -s$(DESTDIR)$(install_prefix)/share/moose/gui/MooseGUI.py$(DESTDIR)$(install
_prefix)/bin/moosegui

is common for
(a) a person doing a source install 'sudo make install', in which
case $(DESTDIR) is blank and $(install_prefix) is /usr . Things go
fine here.

and

(b) for making the debian package, dh_install sets $(DESTDIR) to be a
local subdirectory where it wants all installed files for further
packaging. Later it strips away the local subdirectory path from all
the installed files, but it cannot strip away a soft linked path.
Hence I have put an overriding command to re-link in the postinst
script.

Thus, for both cases things work fine. You can install the deb file
and it should work fine.

Best,
Aditya.



>From ak...@na... Wed Nov  7 13:19:55 2012
Date: Wed, 7 Nov 2012 13:19:54 +0100 (MET)
From: Alexander Kozlov <ak...@na...>
To: Aditya Gilra <ad...@nc...>
Cc: Niraj Dudani <ni...@nc...>
Subject: Re: parallel moose?

OK, I see, deb package is fine then.

(Few more notes-- minor things, not bugs.)

1. Nevertheless, the Makefile instructions are misleading. Non-debian
packagers (Slackware, ARCH-Linux, CRUX, etc) will have to patch it or avoid
the whole 'install:' section.

2. Also, 'install:' introduces unnecessary dependencies on rsync and gtk+
(update-icon-caches) which are not listed in README.

3. Build depends on numpy headers installed or linked to

    /usr/include/python${PYTHON_VERSION}/numpy

This is Debian specific and not general. Default path for numpy headers is

    /usr/lib/python2.7/site-packages/numpy/core/include

To fix the build, I had to add extra path to CXXFLAGS:

    sed -i 's/pymoose: CXX.*/& -I$(shell python -c "import numpy;print
numpy.get_include()")/' Makefile

4. Not mentioned in README, make needs SVN=0 to build the package

    make SVN=0 BUILD=release

or

    make SVN=0

Would be nice to have it disabled by default in release.
In the rest it builds fine on my machine.

5. To run Demos/snippets, one needs matplotlib, python-dateutil and
setuptools to be installed. These should be mentioned in README too, I
think.

With best regards,
Alexander.




>From ad...@nc... Wed Nov  7 14:06:33 2012
Date: Wed, 7 Nov 2012 18:35:57 +0530
From: Aditya Gilra <ad...@nc...>
To: Alexander Kozlov <ak...@na...>
Cc: Niraj Dudani <ni...@nc...>, Subhasis Ray <sub...@nc...>
Subject: Re: parallel moose?

Many thanks Alex! Will incorporate these changes soon... Subha,
perhaps you could look into the build stuff.
Perhaps we should move such discussions to the moose-devel list, so
that discussions are publicly archived? What do people say?

Best,
Aditya.



>From sub...@nc... Thu Nov  8 07:40:53 2012
Date: Thu, 8 Nov 2012 12:10:40 +0530
From: Subhasis Ray <sub...@nc...>
To: Aditya Gilra <ad...@nc...>
Cc: Alexander Kozlov <ak...@na...>, Niraj Dudani <ni...@nc...>
Subject: Re: parallel moose?


On Wed, Nov 7, 2012 at 6:35 PM, Aditya Gilra <ad...@nc...>
wrote:

       Perhaps we should move such discussions to the
       moose-devel list, so that discussions are publicly
       archived? What do people say?


I agree.

       On Wed, Nov 7, 2012 at 5:49 PM, Alexander Kozlov
       <ak...@na...> wrote:
             OK, I see, deb package is fine then.

             (Few more notes-- minor things, not bugs.)

             1. Nevertheless, the Makefile instructions
             are misleading. Non-debian packagers
             (Slackware, ARCH-Linux, CRUX, etc) will have
             to patch it or avoid the whole 'install:'
             section.

             2. Also, 'install:' introduces unnecessary
             dependencies on rsync and gtk+
             (update-icon-caches) which are not listed in
             README.

             3. Build depends on numpy headers installed
             or linked to

              /usr/include/python${PYTHON_VERSION}/numpy

             This is Debian specific and not general.
             Default path for numpy headers is

             
             /usr/lib/python2.7/site-packages/numpy/core/include

             To fix the build, I had to add extra path to
             CXXFLAGS:

              sed -i 's/pymoose: CXX.*/& -I$(shell
             python -c "import numpy;print
             numpy.get_include()")/' Makefile


Thanks, this is useful. At some point we aim to switch to python
distutils or some other advanced build management system. Hopefully
detecting paths will be much simpler then.


             4. Not mentioned in README, make needs SVN=0
             to build the package

              make SVN=0 BUILD=release

             or

              make SVN=0

             Would be nice to have it disabled by default
             in release.
             In the rest it builds fine on my machine.


Good point. It is a developer feature to incorporate svn revision
number for runtime queries. We should have set it to 0 in the
release.


             5. To run Demos/snippets, one needs
             matplotlib, python-dateutil and setuptools to
             be installed. These should be mentioned in
             README too, I think.


matplotlib is required anyways for the gui. I am not aware of
python-dateutil or setuptools being used in the Demos/snippets. Can
you specify the suspect scripts?
Best,
Subha



>From ak...@na... Thu Nov  8 09:24:25 2012
Date: Thu, 8 Nov 2012 09:24:25 +0100 (MET)
From: Alexander Kozlov <ak...@na...>
To: Subhasis Ray <sub...@nc...>
Cc: Aditya Gilra <ad...@nc...>, Niraj Dudani <ni...@nc...>
Subject: Re: parallel moose?

> > > 5. To run Demos/snippets, one needs matplotlib, python-dateutil and
> > > setuptools to be installed. These should be mentioned in README too, I
> > > think.
> > > 
> > > 
> matplotlib is required anyways for the gui. I am not aware of
> python-dateutil or setuptools being used in the Demos/snippets. Can you
> specify the suspect scripts?

Actually, README is correct listing matplotlib only as a requirement so I
should withdraw my objection.

matplotlib (run time dep: python-dateutil (build dep: setuptools))

All included, and should be installed as package dependencies.

Thanks for your comments and sorry for noise,
Alex.

[Moose-generic] Announcing the "Moose Generic" mailing list

[Niraj D. <ni...@nc...>]

Dear subscribers of the 'moose-generic' mailing list,

This is to announce that this mailing list is alive, and is the right
place for discussing general MOOSE issues, and contacting the MOOSE dev
team with problems. Feel free to write to this list -- we'll love to
listen to feedback! :)

In other news, MOOSE 2.0.0 was released very recently. You can find the
release notes here:
   -
https://sourceforge.net/projects/moose/files/moose/Moose%202.0.0%20Kalakand/RELEASE_NOTES.txt/download

Other links of interest are the main website, and the road map for
development in the near future:
   - http://moose.ncbs.res.in/
   - http://moose.ncbs.res.in/component/option,com_wrapper/Itemid,95/

We'll love to hear from you: Do take the new version out for a spin, a
glimpse at the road map, source code, and the excellent new documentation
(for users and for developers). All of this can be found on the MOOSE
website.

Best wishes to all,
Niraj