帮助与文档
EVS
  • EVS > 
  • 在线帮助 > 
  • EVS Training > 
  • Migration from Studio-32 to Studio-64

Migration from Studio-32 to Studio-64

Migration from Studio-32 to Studio-64

There are a number of profound changes which are likely to impact every prior (32 bit) studio application (.evs file) you have made. All of these changes also affect your importation of EVS-Pro and MVS applications as well (though a significant number of additional issues apply in those cases). We have grouped the errors into categories, with the last one being trivial (meaning you can ignore these errors completely).

1. Estimation Method: This is the new global term for the method to be used for estimation. In previous versions of our software it has had several names including Interpolation Type, Interpolation Method and Method Type. Since the estimation process typically includes both interpolation and extrapolation of the data, these prior names were inappropriate and inconsistent, and all modules which perform estimation now include a selector titled Estimation Method.

This will result in one error for each of the affected modules. In the Output Log shown below, these errors have been highlighted in yellow.

The affected modules include:

  • krig_3d_geology

  • krig_3d

  • krig_2d

  • indicator_geology

  • adaptive_indicator_krig

The consequence of this change is that any prior application will now open with the default Estimation Method for all affected modules, rather than the method you might have specified in the individual modules. It is important that you carefully confirm that you have the correct method selected.

2. Geology Cell Data: All geology data (Geo_Layer and Material_ID) has been moved from being Nodal Data to Cell Data. This affects all applications with stratigraphic layers and the modules:

  • 3d_geology_map

  • krig_3d (since it creates layers from krig_3d_geology's surfaces)

  • geologic_surface

  • geologic_surfaces

  • post_samples

  • make_geo_hierarchy

  • any module that is coloring geology data from the above modules

The consequences of this change are the most pervasive, and require the most effort on your part to adjust the settings in the individual modules to carefully confirm that you have the correct outputs in your application. Custom datamaps that were previously applied to nodal data must be copied to cell data (but this is easy).

3. Kriging Data Component Enhancements: krig_3d and krig_2d have new data component selection options which allow you to simultaneously choose any or all of the statistics, min-max plume and other data (e.g. depth, elevation, layer_thickness, etc.) for output. By default all are ON. This means that you will always have more data components coming out of the kriging modules than you did before, likely in a different order.

The consequences of this change are also quite pervasive. Any module that operates on nodal data components downstream of kriging modules will likely select the wrong data components when you load the application unless they are selecting the first one.

You can resolve this problem in a combination of ways:

  • You can choose only the data components that you need in your output. Even though you may choose the same data you had before, the order may be different, and you will not have the geologic data which is now cell data. For that reason, downstream modules will almost certainly be affected. Unless you have limited memory on your computer, you can leave all of the data selected and deal with the issue downstream.

  • If the output in the viewer is not correct look to each module connected to the viewer, and potentially to those upstream to make sure the data you need is selected.

4. Cache Size: In all prior versions of our software (which were all 32-bit applications), any object which connected to the viewer had a default Cache Size in MB. If your model was large and required a larger cache of memory, it would not display and an error would alert you that you needed to increase the cache. The 64-bit application has allowed us to eliminate any cache restrictions and therefore this parameter has been eliminated. Since it is gone, it is creating an error message, but the error is completely harmless and can be ignored. In the Output Log shown below, these errors have been highlighted in Orange.

All of these issues are relatively simple to correct, but there will be a significant number of warnings and errors when you load your prior Studio-32 applications. Once you make the adjustments to your modules and re-save, the errors should be gone on the next load.

Please back-up your old applications first.

The application below is one of the Studio Projects version 2016.2.1 applications.

 

which created the following output in Earth Volumetric Studio version 2016.2.1

 

Upon loading this application in Studio-64, the output log displays the following errors and warnings:

Please notice that the bulk of the errors for this application are related to krig_3d. However, the changes to krig_3d that result in these errors do not necessarily require making changes in krig_3d, but rather require making changes in all affected modules downstream of krig_3d. And since krig_3d is near the top of our application, these changes can affect many modules.

As you can see, when we import this application, the viewer is not showing the model correctly.

The plume is correct, and the reason that it is OK is because the data component for TOTHC was and still is the first data component. But the coloring of the geologic layers on the back side of the cutting plane are now being colored by Confidence with a (leftover node data) datamap that was intended for geologic layers.

It is important that you understand what has changed in krig_3d. As stated above, one of the biggest changes that will affect your applications is the quantity of nodal data and cell data components which krig_3d now creates. In Studio-32 there were two fundamentally different kriging options which we referred to as Statistics or MinMax. These options are now gone and the default kriging output now includes the outputs of both options and more. This was not done in the 32-bit software to conserve memory, but the ability to have all options simultaneously is very powerful and as a 64-bit application, the memory limitations are effectively gone. However, you have the option to selectively include any or all of these data.

In Studio-64 there are three categories of data which are output with kriging and by default all are included. The first two categories (marked by blue arrows) are nodal data, and the third is cell data.

The first affected module in our application is cut. Previously nodal data components of TOTHC, Layer Thickness and Material_ID were selected, but as you can see below, that is no longer the case.

I've unchecked Confidence and Uncertainty and have checked Layer Thickness and Depth (don't really need it, but it can be useful). We also want to select Material from the Cell Data.

Now we have to modify the module that was coloring the geologic layers. Since we want to color by Material, we need to clear all nodal data and select material. If there were pinched layers, we would need to use the Layer_Thickness for subsetting.

 

Below you can see the primary issues related to the post_samples errors. Instead of having a Radius Min and Radius Max, we now have:

  • Glyph Size

  • Priority

  • Minimum Scale Factor

  • Maximum Scale Factor

These parameters give you complete control over the sizes of spheres or glyphs and their correlation to data.

© 1994-2017 kulunsoft.com


0 个评论

要回答文章请先登录注册