documentation on wrappers need a substancial update

The new wrapper documentation is almost ready. It only needs a recheck before being released. But I'm too busy for the moment to have it achieved. I hope this will be done by the end of the year as it was initially scheduled in ticket #93. Be patient.

It's true that the wrapper functionality has highly moved since its former release and I may have made some mistakes or typos (as I did in wrapper.c).

For the last part of your comment, I must mention you need not have the conf files listed in the xml description file. If you list them in it, you ask OT to manage them for you. But if you don't, you have to do it yourself: you may think this is a better solution for your particular issue if you have a more complex management to do. Nothing prevents you from calling a shell script from the wrapper, this script doing a lot of things, like conf file management, besides calling your actual code. It's up to you.

Ivan

Thank you Ivan for your answer.

As the mail addresses are put in clear in the messages, I submitted the bug anonymously so I didn't have any notification of your answer.

I find your changes great in the wrapping mode. I just ask for more advertisement :)

On the xml part of your answer, I disagree. Indeed, now that the files are copied in a temporary directory, it is easier to declare all the required files in the xml. It assures that they will be copied at the correct place. Or maybe I misunderstood something which is highly probable ;)

But if I don't declare them, the computation crashes because files are missing.

Thanks again for your great work !

Jayant

Replying to jayant.sengupta@eads.net:

On the xml part of your answer, I disagree. Indeed, now that the files are copied in a temporary directory, it is easier to declare all the required files in the xml. It assures that they will be copied at the correct place. Or maybe I misunderstood something which is highly probable ;)

Jayant,

You may have software that make heavy use of very large amount of static data. I mean you may have some big database of predefined elements that are always used when you do some computation: for instance a 150 years' history of weather sampled data over a whole continent. If you put the files containing the database in the XML description file, you ask OT to copy them for you to the final directory. But copying the whole database is useless, time and storage consuming. If you needn't copy the files (because they are static, or 'static const' if you prefer a C++ terminology), I think it is better not to mention them in the XML description file but to let the wrapper know where they are living, so you may either point to them during the computation or make some symbolic link to do the same.

And many thanks for your encouragement.

Ivan

Replying to dutka:

Thank you Ivan,

I understand now the files you are talking about and I agree with you.

For the python wrapping mode, do you have examples of multiple simultaneous calls to the same wrapper? I've got ideas to do that but if you have something to get me started, I would gladly appreciate :)

Bye Jayant

Replying to jayant.sengupta:

For the python wrapping mode, do you have examples of multiple simultaneous calls to the same wrapper? I've got ideas to do that but if you have something to get me started, I would gladly appreciate :)

Jayant,

by python wrapping mode, do you mean using a python function as a NumericalMathFunction ? If so, I think it is not immediate to have the python function being called simultaneously. If you want to take advantage of multithreading, I think I must do some coding to have this work. Tell me what you're interested in.

Ivan

Ivan,

Yes python wrapping mode is the use of a python function as a NumericalMathFunction. I say wrapper because i use a python script to call a command line (for salome and aster for instance). My idea: a method of the NumericalMathFunction which takes a NumericalSample instead of a NumericalPoint. for each of the NumericalPoint extracted from the NumericalSample, call the the existing method. The added feature is that each method working on the point has to be ran in a temporary directory (like what is done in the c/c++ wrapper). Unfortunately, I am not enough involved in the development to foresee the difficulties (memory, implementation, etc) of such a way of working. It should not be the equivalent of the BlockSize parameter of a MonteCarlo simulation because they do not have the same role from my point of view (BlockSize to control how many checks I will make on the convergence criteria which is really different from the number of computations I could run at the same time).

Of course, this is maybe stupid :)

Have a good day and nice holidays :D

Jayant

Jayant,

Sure this isn't stupid !

For the moment, the python wrapping mode was just an experiment proposed to users to see if this could match some of their needs. So it wasn't completely developed. But if the proposal seems to be a good guess, I can enhance it.

If you're interested in some evolution of the PythonNumericalMathFunction, open a new ticket describing your needs. It will be easier for us to schedule the task if it is clearly described and registered.

Ivan