Loss Proof Your EVS Work

Published March 2024 - Based on EVS Version 2024.3.0

BACKGROUND

My EVS Project Evolution

  • Regardless of your level of expertise, my EVS applications often evolve in a non-linear fashion, but can benefit from a more structured approach. My initial effort is always understanding the data. The questions I am seeking to answer are:
    • What do the data sets, as a whole, represent?
    • What kind of grid suits my project best?
    • What type of geology am I dealing with?
    • If there is analytical data, what is the story I want to tell?
  • Once I understand my data, I create my models and select the subsetting and visualization options which best tell my story.
    • I am frequently trying something and later changing or refining.

RULES TO MINIMIZE THE RISK OF LOSING HOURS OF WORK.

During all stages of your EVS project development, you need to employ a methodical process of saving your work. However, there are important steps that if followed, will minimize the risk of losing valuable time (and sanity).

  • RULE NUMBER ONE: Save your application with a NEW name whenever you’ve made a significant change.
    • The obvious question is what is significant?
      • This is a personal definition that only you can answer.
      • For me it is ~15 minutes of real work.
    • Therefore, I strive to save my work with a new name every 15 minutes or whenever I make big changes which involves module additions or deletions.
      • What is a new name? I just add a dash and a revision number to my initial naming convention.
      • If my project is Roadrunner-blood-spill.evs then my first revision is Roadrunner-blood-spill-1.evs
  • RULE NUMBER TWO: For full protection, you must regularly re-open your recently saved EVS revisions.
    • This is the only way to detect if some recent action on your part caused an instability in your application which could render your application unable to be loaded.
    • Once you understand the consequences of your application becoming unstable, especially if you lack functional back-up revisions, you will hopefully take this advise more seriously.

WHAT ARE THE SIGNS OF APPLICATION INSTABILITY.

These are a few of the things you may encounter which should signal you that your application is unstable. Please note that there are few ways to repair this condition, so the actions I recommend both above and below are critical. This is definitely a situation where prevention is more powerful than any available cure.

  1. Worst Case: The worst thing you may encounter is that your application will not load. This means that the last time you saved, your application was already unstable. Pay attention to the signs below for instability and try to avoid saving, but in all cases don’t save over a known working revision!
    1. Empty Application Option: The only possible solution when this happens is to move (or copy) your application to a new folder, away from the data files referenced in the application.
      1. You may then be able to open this “empty” application.
      2. Work from Top-Down and one-by-one read your data files to try to find the cause of the instability.
      3. As you successfully execute branches of your application, save your application with a new revision name.
      4. Note: If the empty application cannot be opened, there is no other recovery option.
  2. Application Unresponsive: If you find that your application is not responsive, it may be unstable.
    1. Don’t jump to this conclusion too quickly. If there is activity in the Output Log, this will make the application seem to be unresponsive, but it is actually BUSY. Busy is very different than unresponsive.
    2. An unresponsive application will typically not allow you to open a module’s properties. If the Output Log doesn’t show any activity, and a double-click on any module (or output port) in your application will not open its properties, your application is unstable. Saving the application is likely not useful and may not even be possible. But if you save it be sure not to save over a working version.
  3. Application Stuck in Execution (a.k.a. Busy): If you find that your application is not responsive and the Output Log is active but not making progress, your application may be stuck.
    1. Again, don’t jump to this conclusion too quickly. Some modules may run very slowly with large datasets. Others have stages of their outputs that can take time and do not show progress. Examples are the smoothing process of lithologic modeling and while writing CTWS files with export web scene.
    2. Termination Option: If many minutes pass without progress, some modules have a Terminate button which may work. Terminate button Terminate button
      1. Be aware that it may take a few minutes for the termination of the process to complete, so have some patience. Obviously the more work you may lose if this fails, the more patient you should be.
      2. If termination is successful, you’ll want to check your modules settings and verify that there are not problems with the modules input data file. Both can cause long run times.
    3. Stuck: If the execution is truly stuck, which is indicative of it being in an infinite loop, there will not be anything you can do other than to close EVS. If EVS is unresponsive to the Window close [X], you’ll need to use the Task Manager to close it.
      1. There are two possible solutions in this case.
        1. If the fault is your data, fix the file and reopen your application.
        2. If the fault is settings in the offending module, use the Empty Application Option above.

WHAT ARE THE POTENTIAL CAUSES OF APPLICATION INSTABILITY.

Unfortunately, our users continue to find new ways to destabilize their applications or make them lock-up. However, we do see common threads among these problems and below you will find a description of the types of things you may be doing that increase your risks.

  1. Application Bloat: Excessively large applications are the most commonly problematic and generally represent the greatest investment of time. In Optimized EVS Applications we offer guidelines which we’re confident will reduce the number of modules in your application and help you avoid instabilities.

  2. Summary: If you choose to develop 100+ module applications, you face the greatest risk of loss and you have the most to lose!

  3. Problem Data: Problems with your data can result in application instability. These tend to fall into two categories.

    1. Malformated Data: If you use C Tech’s export tools to create your data files, it is unlikely that your file will be malformatted, but it is still possible if their are certain non-standard characters in your Excel source file(s).
      1. Be very careful if you are manually editing or creating your data file.
      2. If you follow my recommendations above, you’ll be encountering this problem at a stage where your application is already saved and is quite simple.
    2. Unusual Data: I must acknowledge that among our thousands of software users we do encounter a few data files each year which are not malformatted but are problematic because of their nature and our software.
      1. Past examples of this are polylines or surfaces with zero-length edges resulting in redundant-coincident nodes.
      2. We consider this a software bug and endeavor to make our software robust enough to handle these problems, but we cannot plan for something we haven’t seen and can’t imagine.
      3. The Empty Application Option tends to work in these cases if you can’t just fix the file and re-open the application.