Loading...

adun-dev@gna.org

[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: [Adun-users] [Adun-dev] BFGS crashes for a gas phase calculation Michael Johnston Wed Feb 01 17:02:39 2012

2012/1/13 Jordi Villà i Freixa <[EMAIL PROTECTED]>

> he output to check?
>>>
>>
>> Normally - but in this case the exception kills the program before it can
>> output it.
>> I have changed the error to report the system size.
>>
>>
>> in general, it would be good having a protocol for adding error
>> descriptions, even if some of us are not expert programmers. If error
>> messages would be handled in a separate file with some sort of linking id #
>> from the code, we could add messages that describe the problems in
>> physicochemical terms when needed. I have the feeling right now that the
>> program is too focussed towards computer scientists and lack
>> physicochemical "humanity". How do you think we could implement that?
>>
>
> One difficult facing such a method is how can you output a formatted
> string giving information on values in the code without knowing what the
> corresponding variables are in the program e.g. you couldn't write a string
> to log the proteins dimensions, the current size of the space, and the
> max-size limit without knowing the variable they are stored in.
>
> However if you just wan't to give a generic description of the problem
> plus some solution/recovery info this could be put in an external file.
>
> First you have to identify what all these physicochemcial problems are and
> map them to the corresponding errors in the code. To work each code error
> will have to be uniquely associated with a physiochemical problem -
> otherwise you have to add further code to detect which type of
> physicochemical problem a certain error implies defeating the purposes of
> having it in a separate file.  In addition we can't just use the errors
> message as they are as in some cases they are generic - so if you changed
> the string for one problem to make it more specific, you'd then get the
> same message for a different problem.
>
> If you can give a list of the typical problems/errors we can start from
> there.
>
>
>
> some stupid examples that just occur to me (others will arise while
> running actual simulations and seeing how the program responds to different
> situations):
>
> -"The number of interactions in your system is too large to be hjandled in
> this computer and you exceeded its memory. Try some of the following: a)
> reduce the number of atoms; b) reduce the size of the water sphere in an
> explicit solvent simulations; c) reduce the cutoff for non-bonded
> interactions"
> -"Your minimization seems to have exploded: check the energy values
> reported above and eventually try a smaller stepsize"
> -"Your simulation for T=", XXX " is giving some problems; try to reduce
> the tempreature or the step size"
> -...whatever
>
> In MOLARIS, for example, a simple system was used to handle this. Recall
> first that MOLARIS is written in fortran, with its pros and cons.
> Essentially, if some exception is caught, the program goes to a particular
> line that kills the execution cleanly (like it is done with exception
> handling in the ObjectiveC code of Adun, of course). In addition, it gets
> an error ID that explains what has happenned, leading to an additional
> fortran file that only contains a list of print statements. In some cases,
> those print statements contain variables that have been sent to them from
> the place the error was caught.
> Finally, and before crashing, the program (in the part of the code that is
> actually rising the exception) prints information about the particular
> variable that has created some problem. In this way there is both
> information for the user to know what was wrong, but also immediate
> information for the developer to monitor the status of such variable.
>
> As MOLARIS is written in fortran, most of the run time problems relate
> with the static character of the executbale, that prevents indexes in
> arrays to go beyond their pre-established size at compilation time. This
> way the error is very clear and can be fixed in seconds by recompiling the
> code (in that fortran-based case) with the appropriate size.
>
> Of course ObjectiveeC does not produce static executables as Fortran does,
> but an analogous mechanism can be applied with limited cost.
>
> In particular for Adun, a very simple option would be having an external
> text file that contains lines containing a number corresponding to the ID
> plus a text. This can be controlled by developers as it will be in the Adun
> distribution.
>

This is exactly what I was suggesting above - and we can do this relatively
easily for the errors that are there as Adun already associates specific
numbers with specific errors. e.g.
http://home.gna.org/adun/group__framework_types.html#ga8b01e202223e7a5392904ee7f87e9f99

and

http://home.gna.org/adun/group__core_data_types.html#ga155fe78488adb929a1fa0d22917dfc49

however there are relatively few separate situations identified.

So what we be good to start with is an initial list of the situations where
errors should be reported - as without the corresponding 'error code' being
added to the program, and the error being created in the first place, the
value of the external file is limited.



> In addition, this opens the possibility for us to build a page in the adun
> web site containing all the different errors and allowing the users to
> report questions and solutions on them. This will surely help fix recurrent
> problems and we can advanced the improvement of the code with the help of
> the user as well as the developers. In a way, this is making some order to
> the adun-users list.
>

This would be good - however there is a bit of a chicken and egg here -
unless the error is already known there will be no entry on the page. And
if it is known it should already have a solution?


>
> Finally, and this is extremely important, the error messages I am
> referring to need to appear in the log file, right in the place after the
> problem has ocurred, and we should avoid using an errors file diconnected
> from the log file, unless it contains advanced information that can help
> the adun developers to track the problem. The latter only produces
> confussion to the user, IMHO.
>

I've updated the code so final error message is logged to both files.

But to reiterate it is not an error file - the two files are for separating
fine detail from succinct summary information. Think of it as
AdunCoreSummary.log and AdunCoreDetails.log. From experience it is very
useful to separate different types of print outs - apps that output
everything together can become very annoying in practice as you sometimes
have to trawl through hundreds of lines to find relevant information. I
think a file that can be read quickly to get an overview of whats going on
is useful both to developers and users.



>
> In other words, we need to make adun more user friendly and assume the
> user will be able to fix problems from his/her input file, and not to
> request the assistance of the developers every time he/she uses a large
> step size by mistake.
>
> Please, let me know your thoughts
> --
> Jordi Villà i Freixa
> Computational Biochemistry and Biophysics lab
> Research Group on Biomedical Informatics (GRIB) - IMIM/UPF
> Parc de Recerca Biomèdica de Barcelona
> C/ Doctor Aiguader, 88; 08003 Barcelona (Spain)
> Tel: +34 93 316 0504 // Fax: +34 93 316 0550
> e-mail: [EMAIL PROTECTED]
> http://cbbl.imim.es
>
>
> _______________________________________________
> Adun-dev mailing list
> [EMAIL PROTECTED]
> https://mail.gna.org/listinfo/adun-dev
>
>

This message has been automatically forwarded to you by the Adun team 
http://adun.imim.es
_______________________________________________
Adun-users mailing list
[EMAIL PROTECTED]
https://mail.gna.org/listinfo/adun-users