Multiple file directories in Neuron

[matiasm]

Hi,
I am fairly new to Neuron and I am stuck with a small problem. I am trying to record data into various folders and file names. i want the files to be put into folders named by the conductance and the file name to be the current clamp amplitude. This is the code I am working with but can't seem to get it working.

strdef fname
objref file_out
file_out = new File()

for kk=0,NumberLoopsIstim-1{
sprint(fname, "/data/%g%g/%g.dat", ghdbar_hd, gbar_lva, ampli)
file_out.wopen(fname)
//data to collect//
file_out.close()
doEvents()
clamp.amp=clamp.amp-0.001
}

I always get a "File not open: /data/1e-126e-05/0.002.dat
" error. I think it is because the file_out.wopen(fname) doesn't open a file in the directory /data/1e-126e-05 but I am not sure how to fix this. Any help is greatly appreciated.
Thank you
Matias

p.s I have figured out that the reason it doesn't work is because the folders I am trying to create haven't been created. Is it possible for Neuron to create these folders? I am trying to structure the folders all into a data folder and then into numbered folders:
eg. /data/001/file01.dat
/data/002/file02.dat
etc

[ted]

If necessary, use hoc's system() command to create directories. Figure out what to do when a directory already exists.

[matiasm]

great thanks for the reply!! I now have this code added.

chdir("getcwd()")
sprint(folder, "folder1")
system("mkdir %s", folder)
sprint(fname, "%s/%g.dat", folder, ampli2)
file_out.wopen(fname)

Only thing is that the system prints out %s instead of the string I want it to print. Is there a way to make it print the string? I need Neuron to make folders based on changing strings or incrementing numbers, and there might be around 100-150 folders made per program.
Thanks
Matias

[matiasm]

Ok I have found a round about way to solve this. I'm not sure if this is the most efficient way but it works:

sprint(folder, "%g%g%g", gbar_lva, ghdbar_hd, gbar_nap)
sprint(string, "system(\"mkdir data/%s\")", folder)
chdir("getcwd()")

execute(string)
sprint(fname, "data/%s/%g.dat", folder, ampli2)
file_out.wopen(fname)

'folder' contains the name of the new folder I want to make. 'string' contains the command I want to execute, in this case making a folder.
Thanks for letting me know about the system() command. I couldn't have done it without it.

Matias

[ted]

Only thing is that the system prints out %s instead of the string I want it to print. Is there a way to make it print the string?

Yes, but rather than have me tell it to you, you'll learn more if you discover it for yourself. Suggestions for making your cycle of revision and testing easier:

1. Don't run tests that are hard to evaluate. Run tests on simplified code whose performance can be evaluated quickly and conveniently. In this particular case, comment out
file_out.wopen(fname)
and insert the statement
print fname
instead. You'll know instantly whether your sprint statement did what you want.

2. When a cycle of repeated testing and revision becomes necessary, do it in a way that saves you time and effort. Suppose you have a program called myprog.hoc which works up to a certain point, and then fails. You have isolated the problem to a particular set of statements, and you need to debug them.

Edit myprog.hoc. Comment out everything from the start of the problem statements to the end of myprog.hoc.

Use a text editor to create a file called test.hoc
Inside this file put the following code:

Code: Select all

proc test() {
  . . . the statements you are trying to debug . . .
}

Save test.hoc, but keep the editor open so you can easily revise test.hoc again and again, if need be.

Now at the system prompt execute
nrngui myprog.hoc
The program will execute up to a point and then stop.
Do not exit NEURON. Instead:

Code: Select all

At NEURON's oc> prompt, execute the statement xopen("test.hoc")
If the code in test.hoc doesn't work properly, repeat:
  revise and save test.hoc (keep the text editor open!)
  use the keyboard's up arrow (in the xterm where NEURON is running)
    to recall the previous command, which of course was xopen("test.hoc")
  press the return key, and discover if your revised code works
until your revised code works.

[ted]

You're welcome, but I didn't do you much of a favor. You now have code that works properly under one OS, but is likely to fail under other OSes. A pain if you ever collaborate with someone who uses a different OS.

Also, building the names of directories and files out of parameter values doesn't seem like a great strategy for managing families of simulation results--especially when the names become mind-numbingly long. Violates the KISS principle. You don't really want to have to navigate complex directory structures that have wierd, easily misread names.

It seems better to give each unique set of parameters a unique name (a short alpha string, perhaps chosen to be slightly mnemonic, plus a unique identification number which might be date and time at which it was completed). If your program generates only a single output file, you can keep all parameter files* and their associated results in a single directory. Example using YYYYMMDDhhmm date & time format (which sorts nicely):
lowgna201101170924.params
lowgna201101170924.dat
lowgna201101291347.params
lowgna201101291347.dat
*--Parameter files may contain executable hoc statements.

Then you can keep track of all your work in a spreadsheet, or, if you're doing huge numbers of simulations, a real database program, which will make it much easier to design parameter sets, see what has been done, and what remains to be done.

[matiasm]

Dear Ted,

Thanks for the reply. I have it working on windows and mac at the moment, and also on parallel. Seems like it is working across platforms.
You are right about the file/folder names. I have changed my approach to numbering the folders 00,001,002 etc. Each folder contains 20 files output by Neuron.

Thanks again

Matias

[ted]

It's hard to come up with a management strategy that works for all projects. There doesn't seem to be a "one size fits all" strategy. Andrew Davison has been working on something called Sumatra that seems promising
http://neuralensemble.org/trac/sumatra/
His examples are Python-centric, but I suspect that it would work for hoc-based projects as well.