Solved: Minor bug: hand-edited changes to nwch.nw lost under certain conditions


Gets Around
Hi Gary,
I've recently repeatedly encountered a minor oddity in the behaviour in ECCE v6.4 - under specific conditions the nwch.nw file gets
regenerated, so that all hand-edited change are lost.

It's not a show stopper, but it's a bit odd, and causes occasional swearing.

By Editor I am not referring to the vim editor but to the NWChem Electronic Structure Editor.

To reproduce:
1. Create a job in ECCE, hit Final Edit in the Editor and add e.g. maxiter 99 to the dft block. Run the job.
2. When it has finished (either by completion or by failing), open the Editor.
3. With the Editor open, Click on Run Mgmt/Reset for restart.
If you at this point inspect the input file (e.g. Final Edit, or ctrl +I) you will find that the hand-edited changes are gone.

In contrast,
  • if your do NOT have the Editor open when hitting Reset for Restart (i.e. just highlight the job in the manager), the changes persist.
  • If you DO have Editor open but hit the square
    to reset, the changes persist.
  • If you hit Run Mgmt/Reset to rerun, the changes persist

I've put a few screenshots here: http://verahill.blogspot.com.au/2012/11/minor-bug-in-ecce.html

/Andy

PS Another forum bug: you can't put any word after the word
gets

Gets Around
Hi Andy,

Sorry for not seeing this for several weeks. I can reproduce this and agree it's not intended behavior. I've never reset the state this way (I always use the little "R" icon button in the editor itself), but I can see how someone would get accustomed to doing it a certain way and it should work. I can guess how this is happening in ECCE based on how the inter-process messaging works, but I'm not sure precisely how to fix it without diving into it. Hopefully next week I'll have time to do that and put out an updated ECCE 6.4 release. Offhand I do see that it's being too aggresive when a reset IPC message is sent by automatically regenerating an input file. Certainly there's no compelling reason to be that extreme in the case of a "reset for restart" or "reset for rerun".

Best regards,
Gary

Gets Around
Hi Gary,
no worries.
I mainly run into this issue when there's a typo in the input file, which leads to a failed job within minutes, so that the submission window is still open in the background. It's easy enough to work around as long as people are aware of the behaviour.
Cheers,
Andy

Gets Around
Hi Andy,

I just pushed out new binary and source code distributions for ECCE 6.4 that should fix this bug. It was a couple lines of code related to the inter-process messaging that was being triggered with the "reset for restart" and "reset for rerun" actions in the organizer that were causing a new input file to be generated when it wasn't necessary. Whenever an input file is generated it loses any "final edit" changes as there is no "merge" capability, which would be a really nice addition of course.

Don't hesitate to download and compile the ECCE source code distribution so you can try to track down issues yourself. Even if you're not a C++ or C developer, I still think that you'lll be able to figure out more than you would imagine and start sleuthing or add some enhancements. If you do end up making changes to ECCE code, let me know and I will take a look and move what makes sense into our ECCE subversion repository so they are pushed out for everyone.

Best regards,
Gary

Gets Around
Cheers Gary,
I compiled the newest sources and everything is looking -- and working -- great.
(http://verahill.blogspot.com.au/2013/01/325-compiling-ecce-64-on-debian-testing.html)

On a related note, is there anywhere I can change the version number (to e.g. 6.4.0 or 6.4b) -- if I start editing the code and recompiling it might be safer if I can track what version I'm actually using.

Best regards,
Andy

Gets Around
[deleted by author -- turned out to be hardware issue]


Forum >> ECCE: Extensible Computational Chemistry Environment >> General ECCE Topics