moose-devel — Development issues

[moose-devel] Using HSolve for a bunch of neurons

[Saeed S. <sd....@gm...>]

Dear all,

I am trying to use HSolve for two neuron which are located at
/network/cell1 and /network/cell2. I set HSolve target field to /network,
but it seems that the HSolve just consider the first cell and the second
cell does not zumbify.

Would you please help me to know how can I use hsolve for a bunch of
neurons?
Does it create a HSolve object for every neuron?
What can I do if I want to send a pool of neurons to hsolve?

I am looking forward to hear from your

Best Regards,
Saeed

Re: [moose-devel] Is gui in truck is any advance than the gui in buildQ branch

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

On Tue, Oct 8, 2013 at 6:51 PM, Dilawar Singh <dil...@ii...> wrote:
> Does stable release of moose-gui has more feature than buildQ branch (mgui.py)
> file?

Yes, the gui in buildQ branch does not display 3D neuronal models yet,
but loading models, running simulation and plotting should work fine.
Hopefully we shall have the neuron visualization soon incorporated in
this (which should be much faster than the earlier one).

>
> I want to fix some "name-error" in gui code in buildQ branch. Is it ok to touch
> that code. Or should I copy that folder into my personal folder?

Can you give a stack trace? Then I can look into it.

- Subha

Re: [moose-devel] No attribute moose.Pool.volume found

[Dilawar S. <dil...@gm...>]

Resolved. I had a old-moose installed in /usr location. The script was linking
with _moose.so from this location rather than the buildQ branch. Removing those
files fixed it. 

Changed the .size to .volume again.


-- 
Dilawar
NCBS Bangalore
EE, IIT Bombay

On Thu, Sep 26, 2013 at 03:01:22PM +0530, Dilawar Singh wrote:
>In the script `buildQ/Demos/snippets/multiCompSigNeur.py`, the line
>
>   assert dendCa.volume == dendSide * dendSide * dendSide
>
>   AttributeError: 'moose.Pool' object has no attribute 'volume'
>
>Changing volume to size works ie scripts run and generates plot which can be
>plotted xplot. Plot is like a normal neural response (pulse). Is Pool.volume is
>added to some other version of moose which is not in buildQ branch?
>
>-- 
>Dilawar
>NCBS Bangalore
>EE, IIT Bombay
>
>------------------------------------------------------------------------------
>October Webinars: Code for Performance
>Free Intel webinars can help you accelerate application performance.
>Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
>the latest Intel processors and coprocessors. See abstracts and register >
>http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
>_______________________________________________
>moose-devel mailing list
>moo...@li...
>https://lists.sourceforge.net/lists/listinfo/moose-devel

[moose-devel] No attribute moose.Pool.volume found

[Dilawar S. <dil...@nc...>]

In the script `buildQ/Demos/snippets/multiCompSigNeur.py`, the line 

   assert dendCa.volume == dendSide * dendSide * dendSide

   AttributeError: 'moose.Pool' object has no attribute 'volume'

Changing volume to size works ie scripts run and generates plot which can be
plotted xplot. Plot is like a normal neural response (pulse). Is Pool.volume is
added to some other version of moose which is not in buildQ branch?

-- 
Dilawar
NCBS Bangalore
EE, IIT Bombay

Re: [moose-devel] Undefined symbol while importing moose in python

[Dilawar S. <dil...@gm...>]

Hi Subha,

I checked-out the buildQ branch. Its working fine now.

--
Dilawar
EE, IITB


On Wed, Jul 31, 2013 at 1:55 PM, Subhasis Ray <ray...@gm...>wrote:

> Hi Dilawar,
>
>
>
> On Wed, Jul 31, 2013 at 1:13 PM, Dilawar Singh
> <dil...@gm...>wrote:
>
> >
> > I build the moose using `python setup.py build`. It complained about
> > unavailability of two files     'ksolve/FuncTerm.cpp',    and
> > 'mesh/ChemMesh.cpp'. I removed them from `setuo_/__init__.py` file. It
> got
> > compiled. When importing moose into python, I am getting following error.
> >
> > ImportError: /usr/local/lib/python2.7/dist-packages/moose.so: undefined
> > symbol: _ZN8ReacBase9setSolverE2IdS0_
> >
> > What am I missing?
> >
> >
> The distutils based setup is not actively maintained. The standard way to
> build moose is:
>
> make moose
>
> in the top level directory and then you can add {moose}/python to your
> PYTHONPATH variable. I am not sure what version of moose you are using, but
> the latest development branch is buildQ.
>
> Best,
>   Subha
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> moose-devel mailing list
> moo...@li...
> https://lists.sourceforge.net/lists/listinfo/moose-devel
>

Re: [moose-devel] Undefined symbol while importing moose in python

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

Hi Dilawar,



On Wed, Jul 31, 2013 at 1:13 PM, Dilawar Singh
<dil...@gm...>wrote:

>
> I build the moose using `python setup.py build`. It complained about
> unavailability of two files     'ksolve/FuncTerm.cpp',    and
> 'mesh/ChemMesh.cpp'. I removed them from `setuo_/__init__.py` file. It got
> compiled. When importing moose into python, I am getting following error.
>
> ImportError: /usr/local/lib/python2.7/dist-packages/moose.so: undefined
> symbol: _ZN8ReacBase9setSolverE2IdS0_
>
> What am I missing?
>
>
The distutils based setup is not actively maintained. The standard way to
build moose is:

make moose

in the top level directory and then you can add {moose}/python to your
PYTHONPATH variable. I am not sure what version of moose you are using, but
the latest development branch is buildQ.

Best,
  Subha

Re: [moose-devel] Undefined symbol while importing moose in python

[Dilawar S. <dil...@gm...>]

I got the source code from svn repository.

--
Dilawar
EE, IITB


On Wed, Jul 31, 2013 at 1:13 PM, Dilawar Singh
<dil...@gm...>wrote:

> Hi list,
>
> I build the moose using `python setup.py build`. It complained about
> unavailability of two files     'ksolve/FuncTerm.cpp',    and
> 'mesh/ChemMesh.cpp'. I removed them from `setuo_/__init__.py` file. It got
> compiled. When importing moose into python, I am getting following error.
>
> ImportError: /usr/local/lib/python2.7/dist-packages/moose.so: undefined
> symbol: _ZN8ReacBase9setSolverE2IdS0_
>
> What am I missing?
>
> --
> Dilawar
> EE, IITB
>

[moose-devel] Undefined symbol while importing moose in python

[Dilawar S. <dil...@gm...>]

Hi list,

I build the moose using `python setup.py build`. It complained about
unavailability of two files     'ksolve/FuncTerm.cpp',    and
'mesh/ChemMesh.cpp'. I removed them from `setuo_/__init__.py` file. It got
compiled. When importing moose into python, I am getting following error.

ImportError: /usr/local/lib/python2.7/dist-packages/moose.so: undefined
symbol: _ZN8ReacBase9setSolverE2IdS0_

What am I missing?

--
Dilawar
EE, IITB

[moose-devel] The International Conference on Cognitive Modifiability * June 2013

[Jerusalem B. c. <dr....@co...>]

‏Unsubscribe me from this
listhttp://conferencebrain.com/data/unsubscribe.php?M=254264&C=e41e783c413a360646f87c34b72157d4&L=7&N=7

   Registration is now

for the

Jerusalem International conference

June 2013

on

Neuro-plasticity and Cognitive Modifiabilty

"The role of Cognitive Intervention in the Shaping of the Wo/Man"

Link for details:

‏ www.brainbrain.info

Powered by Interspire

[moose-devel] 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. Due to a software upgrade at SourceForge.net, the subversion URLs
have changed. Here is how to shift to the new URL:

1) Checkout a new working copy (read/write) using the following command:

    svn co --username=XXXXX
svn+ssh://XX...@sv.../p/moose/code/moose/branches/buildQ

Replace XXXXX with your username. This also seems to work if you skip the first
"--username" argument.

2) If all you need is a readonly checkout:
    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,
MOOSE dev team

Re: [moose-devel] Suggested tools for test and develop code

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

Dear Saeed,
  Development tools are very much a matter of personal taste. But I think
gdb is the standard debugging tool on Linux. And most likely Linux version
of eclipse is also using the same as a back end. As far as front-end is
concerned, you have plenty of choices on Linux:  ddd, eclipse, emacs,
vi(m). You can search the internet for the specifics of each interface.
  For debugging moose you do not require "make install", which is for
copying the libraries to system-wide location. What you need to do is:

1. Build moose in debug mode

make BUILD=debug

This will build moose with debug symbols incorporated into the binaries.

2. Start gdb and set PYTHONPATH
Below I provide sample commands for gdb command line version. This should
be available in all front ends.
After this you want to set the environment variable PYTHONPATH to
{moose_source_directory}/python. Read the GDB documentation on how to do
that:

(gdb) help set environment

will give you a brief description.

3. Enable future breakpoints.
Then you want to read the documentation on "future" breakpoints. To turn
that on:

(gdb) set breakpoint pending on

4. Set breakpoints

After this you can put a breakpoint anywhere in MOOSE C++ code in the usual
way. Remember that the entry point to MOOSE C++ module from Python is the
module initialization function: {moose}/pymoose/moosemodule.cpp:
init_moose. There is a bit of trick here: the function name is generated
using a preprocessor directive, so it looks like:

 PyMODINIT_FUNC MODINIT(_moose)

in the code.

5. Start debugging Python
After this you start Python in gdb (either starting gdb with
/usr/bin/python as the argument or by using "file" command inside gdb.
If you want some particular Python script to be executed, you set that
using "set args"  command in gdb.
Now start running Python:

(gdb) r

If you assigned a script  above, Python will run that script and stop at
the breakpoint on reaching it. Otherwise Python interpreter will run
interactively and you can do the usual

import moose

in the interpreter prompt and execute statements you want to debug.

There is a lot to gdb and reading the documentation will help you not only
with moose but programming and debugging in general.

Hope this helps,
  Subha





On Wed, Dec 19, 2012 at 1:10 AM, Saeed Shariati <sd....@gm...>wrote:

> Dear All,
>
> In developing code at Moose. Processing parts of code are in C++ and start
> point is in Python. I can compile and debug processing part in EClipse.
> Creating another Python project beside of the code and debugging via
> EClipse can be an interesting for development. But, I have some problem to
> config EClipse for this situation.
> Are moose python module applicable after "moose install"? or I can use it
> directly via one EClipse python project?
>
> All in all, would you please counsel me about suggested development tools
> and method for developing and testing moose code?
>
> I am looking forward to hear from you.
>
> Best Regards,
> Saeed Shariati
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> moose-devel mailing list
> moo...@li...
> https://lists.sourceforge.net/lists/listinfo/moose-devel
>

[moose-devel] Suggested tools for test and develop code

[Saeed S. <sd....@gm...>]

Dear All,

In developing code at Moose. Processing parts of code are in C++ and start
point is in Python. I can compile and debug processing part in EClipse.
Creating another Python project beside of the code and debugging via
EClipse can be an interesting for development. But, I have some problem to
config EClipse for this situation.
Are moose python module applicable after "moose install"? or I can use it
directly via one EClipse python project?

All in all, would you please counsel me about suggested development tools
and method for developing and testing moose code?

I am looking forward to hear from you.

Best Regards,
Saeed Shariati

Re: [moose-devel] What is the best method to compare execution time and evaluate performance?

[Upinder S. B. <bh...@nc...>]

Dear Saeed,
     There are a number of tests in the regressionTests directory which 
double as benchmarks. These are currently mostly binary tests, but they 
typically depend on availability of local files for loading models and 
checking output.

Best,
     Upi

On Thursday 06 December 2012 12:33 AM, Saeed Shariati wrote:
> Dear all,
>
> First, thanks to mailing list which provides responses so rapidly.
>
> I want to test execution time of processing threads and profile their
> execution times. As I understand from the code, Moose uses some built-in
> test routines, external benchmarks and also some Demo files which are in
> script.
> I am using EClipse as a code editor and I prefer to execute binary code
> directly via the editor, therefore using Demo files and calling the main
> method from Python is not a good way for this test.
>
> Would you please tell me which one of internal test methods or benchmarks
> could be the best choice?
>
> I want to change thread execution and evaluate the performance.
>
> Best Regards,
> Saeed
>

[moose-devel] What is the best method to compare execution time and evaluate performance?

[Saeed S. <s.s...@uf...>]

Dear all,

First, thanks to mailing list which provides responses so rapidly.

I want to test execution time of processing threads and profile their
execution times. As I understand from the code, Moose uses some built-in
test routines, external benchmarks and also some Demo files which are in
script.
I am using EClipse as a code editor and I prefer to execute binary code
directly via the editor, therefore using Demo files and calling the main
method from Python is not a good way for this test.

Would you please tell me which one of internal test methods or benchmarks
could be the best choice?

I want to change thread execution and evaluate the performance.

Best Regards,
Saeed

-- 
Saeed Shariati
Master student of Neuroscience
Universidade Federal do ABC - UFABC
http://www.ufabc.edu.br/
Rua Santa Adélia, 166, Santo André - SP - Brasil | CEP 09210-170

Re: [moose-devel] A short presentation on Moose

[Upinder S. B. <bh...@nc...>]

Dear Chaitanya, all,

Still not sure on the question in point 2. Though I don't know if 
extracellular electrodes are implemented as yet in MOOSE, they are 
pretty trivial to do in the same way that GENESIS did. Just set up 
messages from each compartment to the extracellular recording point(s). 
If it were a field of electrodes envisioned, that could be done more 
efficiently using a new object and the same messaging, again quite simple.

-- Upi

[moose-devel] A short presentation on Moose

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

>
>   2. External stimulation of a neuron: Is it possible with the current
> moose,
> to model external stimulation of a neuron (ie by changing the external
> membrane potential alone)?  The same in NEURON is apparently laborious.
>
> Unclear what you mean. It is easy to do the usual electrode stimulus
> protocols,
> which amount to fiddling with compartment injection current. It is also
> easy to
> fiddle with Em, the resting potential, and Vm, the membrane potential.
>

Is it possible to model electrodes in extra cellular medium ? Assuming that
we know the extra cellular membrane potentials at every compartment.

[ basically to change 'Extracellular' part :
http://en.wikipedia.org/wiki/File:Cell_membrane_equivalent_circuit.svg ]

I suppose one can play with Em - the resting potential to accomplish this.

3. Scripting handle to Moogli: Sounds very good, I suggest Python. Strong
> recommendation is NOT to write your own!
>

Yes, I intend to use Python. There is also scope to render the graphics
more efficiently (relevant to MOOSE gui as well).

Cheers!
Chaitanya

Re: [moose-devel] A short presentation on Moose

[Upinder S. B. <bh...@nc...>]

Hi, Chaitanya, all,
     Good to hear from you and thank you for teling people about MOOSE 
and Moogli.

Here are some of the answers.

  1. Electroneutrality: During KKIT like chemical reactions, is the
electroneurtrality in the space is preserved? I vaguely remember Upi
discussing this in a lab meet.

No. Not hard to do, but isn't part of the current implementation.


  2. External stimulation of a neuron: Is it possible with the current moose,
to model external stimulation of a neuron (ie by changing the external
membrane potential alone)?  The same in NEURON is apparently laborious.

Unclear what you mean. It is easy to do the usual electrode stimulus protocols,
which amount to fiddling with compartment injection current. It is also easy to
fiddle with Em, the resting potential, and Vm, the membrane potential.

3. Scripting handle to Moogli: Sounds very good, I suggest Python. Strong
recommendation is NOT to write your own!

Best,
	Upi

[moose-devel] A short presentation on Moose

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

Hi all,

Last week, I visited a collaborator's lab (Gaute Einevoll of Norwegian
University of Life Sciences at Aas, Norway) along with some of my current
lab colleagues. As an introductory exchange, each of us (folks visiting
from my Polish lab and few from the Norwegian lab) gave a 15 minute talk on
our respective work. As I did not have anything to present relevant to my
work, I was suggested to speak about MOOSE and Moogli. Which I did.

During subsequent discussion with some of the audience, the following
questions were posed regarding MOOSE. I was not equipped to answer them
best. Perhaps these are obvious to you.

1. Electroneutrality: During KKIT like chemical reactions, is the
electroneurtrality in the space is preserved? I vaguely remember Upi
discussing this in a lab meet.

2. External stimulation of a neuron: Is it possible with the current moose,
to model external stimulation of a neuron (ie by changing the external
membrane potential alone)?  The same in NEURON is apparently laborious.

Perhaps the above are straightforward and hence would make good example
codes if they don't already exist.

Regarding Moogli, there seems to be general interest about it, but a
scripting handle to Moogli seemed to me as a pressing need for it to be of
any use.  Their lab (and my current lab) models LFP's and would like to
visualize these in correspondence with the firing of the neurons. Another
one uses finite element analysis to study potentials at the electrode plane
(similar to my current project now). They currently employ matplotlib and
neuronvisio ( Mayavi based coupled with NEURON)
I work on Moogli this during my spare time. If anyone is interested to
contribute in any way - do let me know.

Cheers!
Chaitanya.

PS: Please correct me if I am using the wrong mailing list.

Re: [moose-devel] Shell execution or profiling mechanism

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

Hi Saeed,

On Fri, Nov 23, 2012 at 12:05 AM, Saeed Shariati <s.s...@uf...>wrote:

> I am new in Moose and I want to involve in development specially in
> optimization and HPC side.
>

Welcome to the  group.

For this case, I need to execute application from shell or in a batch mode.
> Executing from GUI is not a good way to measure the execution time.
>

You can run MOOSE simulations without the GUI. Read the documentations.


>
> Is the any profiling mechanism or any suggestion to check the execution
> time of a model in the case of optimization?
>

You can compile it with profiling support. You need to look at the Makefile
and edit it. I am not aware of any specific profiling mechanism built into
MOOSE. Valgrind works, but it may be prohibitively slow. A simulation is
executed by the start() function [ interfaced to shell/Shell.cpp:
Shell::doStart(...) ]. Again, you can get better idea by first reading the
documentation and then reading the code. You can use gdb (with a
debug-build of MOOSE) to step through the code to some extent and
understand how it works. One warning though, do not use debug builds of
Python, the PyMOOSE interface will fail with an assertion error in the
Python interpreter.

Best,
  Subha

Re: [moose-devel] CPU usage in the idle state and also not using cpu in execution time effectively

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

On Fri, Nov 23, 2012 at 12:06 AM, Saeed Shariati <s.s...@uf...>wrote:

> After starting application, cpu shows 110% usage (4 core cpu) for do
> nothing!
>

By default MOOSE runs one "command thread" and as many "process threads" as
the number of cores. The worker threads look for data in a queue in a busy
loop. This causes the high CPU usage. This is intended for heavy
simulations where you have different components of a large model simulated
on different threads (and cores). You can set the environment variable
NUMPTHREADS=1 to use only 1 process thread.


> And, when the simulation start, it increases near to 220%.
>

That is understandable.


>
> It seems that everything executes on Python.
>

No. Python just sets up the simulation and starts by calling C++ functions.
When you say moose.start(time) in Python, that is a C++ function running
the entire simulation.


> Is it possible to execute the simulation code in a more efficient way?
>

You can look at the regressionTests directory for some examples where the
simulations are executed in C++ without Python.
I would also suggest you read the Programmers guide [
http://moose.ncbs.res.in/index.php?option=com_wrapper&Itemid=65], the
application programming API and the design document to get a handle on the
internals of MOOSE.

Best,
 Subha

[moose-devel] CPU usage in the idle state and also not using cpu in execution time effectively

[Saeed S. <s.s...@uf...>]

Dear All,

After starting application, cpu shows 110% usage (4 core cpu) for do
nothing!
And, when the simulation start, it increases near to 220%.

It seems that everything executes on Python.
Is it possible to execute the simulation code in a more efficient way?

Best Regards,
Saeed

[moose-devel] Shell execution or profiling mechanism

[Saeed S. <s.s...@uf...>]

Dear All,

I am new in Moose and I want to involve in development specially in
optimization and HPC side.
For this case, I need to execute application from shell or in a batch mode.
Executing from GUI is not a good way to measure the execution time.

Is the any profiling mechanism or any suggestion to check the execution
time of a model in the case of optimization?

Best Regards,
Saeed

[moose-devel] Shell execution or profiling mechanism

[Saeed S. <mon...@gm...>]

Dear All,

I am new in Moose and I want to involve in development specially in
optimization and HPC side.
For this case, I need to execute application from shell or in a batch mode.
Executing from GUI is not a good way to measure the execution time.

Is the any profiling mechanism or any suggestion to check the execution
time of a model in the case of optimization?

Best Regards,
Saeed

Re: [moose] Some notes on the user documentation format

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

>   - I tried exporting to PDF, and the PDF was quite garbled up. Apparently
> this is common, and there are alternatives[*] which are supposed to give
> clean PDFs, but they look quite involved. For now I've printed the HTML ->
> PDF manually, for putting up on the site, like Chaitanya suggested.
>

The PDF export works via LaTeX and it was getting confused by non-standard
equations/syntax. These are now fixed in the moose repository. Also, I
suspect that markdown to PDF export may have similar issues with complex
equations.

  - I've seen the 'Markdown' format (similar to Org-mode) mentioned a lot,
> and also the 'reStructuredText' format. Of the three, Markdown seems to be
> the most widely adopted. Also, it will be nice to create HTML and PDF
> output from a script, so that the website can be automatically updated.
> Since Org-mode seems to be mainly tied to Emacs, not sure how simple it is
> to do this. Finally, even though the Org-mode format is already very
> simple, I find Markdown to be the simplest of the 3.
>
> Nothing pressing, and certainly not worth putting in the effort to
> manually re-encode the existing docs. If the need is felt, and if Org-mode
> -> reST/Markdown conversion tools work well, we can consider.
>
> There several conversion tools: pandoc [http://johnmacfarlane.net/pandoc/]
and orgmode-markdown [https://github.com/alexhenning/ORGMODE-Markdown] seem
to be functional.

Major disadvantages of org-mode are (1) it is tied to emacs and (2) it
requires a bit of configuration to be able to export to various formats.
While it is an extremely powerful system (you can even write code snippets
and insert the result of its evaluation into the same document - which can
be useful for interactive tutorials), all that may be an overkill for our
purpose.

The other plain-text formats are definitely worth a look.

- Subhasis

[moose] Some notes on the user documentation format

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

Dear all,

I'm sending this mail to kick off activity on the developer's mailing
list. For now, I'm also CC'ing members of the core team, until we can see
that it is working.

This mail concerns the file format we're using for our documentation
(Emacs' org-mode), and suggests that Markdown may be a better choice. This
is a low level issue, with low importance, but your thoughts are welcome.

----------------------------------------
Issues faced with Emacs Org-mode format.
----------------------------------------

I faced a few minor issues with user-documentation files, which are
encoded in Emacs Org-mode, and thought I'd share. I also mention below
that it may be worth considering switching to Markdown -- thoughts
welcome.

  - I tried exporting to PDF, and the PDF was quite garbled up. Apparently
this is common, and there are alternatives[*] which are supposed to give
clean PDFs, but they look quite involved. For now I've printed the HTML ->
PDF manually, for putting up on the site, like Chaitanya suggested.

  - The HTML files produced work just fine from the local machine, but
were causing the Apache webserver to get confused, and only a blank page
would load. The fix is very simple: One needs to remove the first line
from the HTML, which basically says that this is an XML file. Minor issue,
mentioning for future reference.

 - I've seen the 'Markdown' format (similar to Org-mode) mentioned a lot,
and also the 'reStructuredText' format. Of the three, Markdown seems to be
the most widely adopted. Also, it will be nice to create HTML and PDF
output from a script, so that the website can be automatically updated.
Since Org-mode seems to be mainly tied to Emacs, not sure how simple it is
to do this. Finally, even though the Org-mode format is already very
simple, I find Markdown to be the simplest of the 3.

Nothing pressing, and certainly not worth putting in the effort to
manually re-encode the existing docs. If the need is felt, and if Org-mode
-> reST/Markdown conversion tools work well, we can consider.

Thanks,
Niraj

[*]
http://emacs-fu.blogspot.in/2011/04/nice-looking-pdfs-with-org-mode-and.html