WHEN TO USE SNAP

SNAP is designed to provide good feasible solutions for tactical harvest unit scheduling for up to 30 [50] period problems. SNAP is dimensioned for about 1000 [5000] polygons and 3000 [10,000] road segments. This is subject to change however, depending on the host computer's memory and the current version of the SNAP program.

SNAP is designed for problems with at least 150 units and 250 road segments. For smaller problems, exact solutions might be obtained using conventional mixed integer formulations.

SNAP ALGORITHM

To understand how to use SNAP and to interpret SNAP output it is important to know something about how SNAP works. SNAP does not guarentee an optimal solution to your problem. It is designed to provide good feasible solutions. The solution algorithm used in SNAP goes through the following steps:

(1) SNAP makes an initial pass over the analysis area by scheduling all sales to go in the first period. This provides information on likely harvest systems, road systems, and net values.

(2) Next, SNAP determines a good set of leave units based upon minimization of present net worth loss or a user defined criteria to connect control polygons. If minimization of present net worth loss is the criteria, the relative values from step (1) are used to make a network connecting all eligible seral stages and the problem is solved to minimize loss of value.

(3) Then, SNAP generates a number of harvest patterns that are spatially feasible and meet the harvest flow constraints from the Volume Constraints Editor. Each of these patterns is a solution to the problem.

The first pattern is generated by introducing the sales in order of their relative value based upon their net values as if the entire area had been harvested in the first period (step 1). Subsequent patterns are made by stratifying the ranked list of polygons from step 1 into a number of subgroups and introducing polygons in each subgroup in a random order.

(4) For each pattern, logging system selection and road selection is made simultaneously as each sale is introduced into the solution. Each sale can also "see" what the previous sales have done in terms of road selection and takes it into account for its own choices.

The first pass through the procedure of logging system selection and route selection is called Iteration 0. It is the variable cost solution with the fixed costs added on. If the analyst wants to improve the choice of transportation system he requests "optimize roads" in the General Setup Editor and the solution procedure is repeated so that the first sale can "see" what all the previous sales did and can modify "its choice" based on the new information. This second chance becomes Iteration 1. The third chance becomes Iteration 2 and so on until the SNAP algorithm decides no further improvement can be made.

HOW MANY SOLUTIONS TO LOOK FOR

The more solutions you ask for, the better the chance to find one or more very good solutions. Limited computational experience has shown that you should ask for at least 20 solutions. You can ask for as many as 99 solutions. On a 386 - 33 Mhz computer a 200 unit problem may take about 30 seconds per solution.

One approach to cut down on solution time when you are scoping out the problem is to ask for a large number of patterns to be run for Iteration 0 (no fixed cost optimization) and then select a pattern to look at in more depth with additional iterations. This can be done by exporting a pattern from the Report Writer to the Sale File and using the H-WIRED option in the General Setup Editor.

PROBLEM FEASIBILITY

SNAP contains a lot of options and there are a lot of ways to make your problem infeasible. Adjacency requirements, habitat connection requirements, acreage controls and period volume requirements can all be conflicting. In large runs, it may be quite frustrating to untangle the problem. For example, if you schedule sales with a status that requires them to be taken and this conflicts with habitat control polygons or acreage limitations.

SNAP will try to make reasonable decisions if conflicts occur so that the problem can run to a successful conclusion. We try to avoid situations where a "NO FEASIBLE SOLUTION" message results. This type of message is frustrating and contributes little to the solution process. Review your reports carefully to see that the solution did achieve your objectives, or close to them.

We recommend starting simply. Leave as much wiggle room as possible to get a successful run you can use as a bench mark. After you are sure that your data is clean, then tighten up the problem specification. You spent a long time getting your data together, a little time spent in making sure it hangs together is well worth it.

Some types of problems are:

1. Network not connected - Solution=> Check network connectedness using

connect link option (Alt F4) in the Project Files Editor. If you decide to skip over the network analysis to get your problem up and running, use the Fill option in the Sale editor to make all sales have the same timber entry node and make sure that node is connected to a mill.

2. Mill node not on network - Solution => Check mill file and road network.

3. Insufficient growth data - Solution => Check Silvicultural Treatment editor to verify that each possible combination of seral stage and treatment have been specified. If you can't find problem, then reduce silvicultural treatments until the problem runs and then increase the options.

4. Problem runs, but no acres treated. - Solution=> Check Seral Stage and Attribute Constraint Editor and Silvicultural Treatment and Attribute Constraint Editors. If you cannot pin point the problem, release the constraints and then build up the problem again.

5. Adjacency rules violated. - Solution => (a) Check to make sure polygons have been correctly attributed, (b) Check to see if attribute ties are needed, (c) Check unit status column in Sale Editor to see if there are conflicts. (d) If this is a Hard-Wired Run and you changed the treatment in the Hard-Wire column of the Sale Editor, you might have violated your own rules and what you ask for is what you get.

Occasionally SNAP can get confused. As a last resort

(a) Exit the SNAP program and go into the subdirectory where your data is located and erase the REPO_SET file and run again.

(b) If that does not work, check to see if your polygons have been correctly digitized, i.e, no overlaps and no polygons inside of other polygons.

6. Problem runs, but cannot get a habitat connection. Solution => Verify the seral stages in the Seral Stage Graphic Report. In particular, look at the seral stages at the beginning of period 1. The habitat connections have a high priority in the solution process. The only overriding criteria is the unit status code. You may need to either relax your criteria or bridge an ineligible area by chosing an ineligible polygon and designating it as a critical polygon. Critical polygons do not have to have an eligible seral stage to be in the habitat connection.

7. Problem runs but the seral stage constraints do not seem to be met. Solution => Verify the initial conditions at the beginning of period 1. If the problem already violates the constraints, SNAP may not be able to cure the violation. However, SNAP will try to avoid making the problem worse.

8. Problem runs there seem to be very negative sales in the unit cost report for no apparent reason. Solution => Remember that the schedule is required to be in integer units. Sometimes a very negative sale appears in the unit cost report for no apparent reason. This may be due to several reasons but is often related to the fact that it was one of several species in the unit and if the unit is scheduled, then everything goes.

MEMORY MANAGEMENT

SNAP needs about 550-570 k of DOS memory to run so check to make sure you do not have too much memory taken up by memory resident programs. If you are loading DOS into high memory then see the DOS 6.0 section below concerning extended memory. SNAP III requires at least 570K of DOS memory.

SNAP needs additional memory beyond 640 k to operate on problems larger than 300 polygons. It needs the additional memory for four tasks:

A. To evaluate adjacency information for during initial file building.

B. To give you sufficient room in the SNAP editors (large number of rows).

C. To have enough memory to do the analysis.

D. To have enough memory to rapidly access point and stick data in the Report

Writer.

Memory is of two types: expanded memory and extended memory.

SNAP II will use only extended memory for Tasks A, B, and D. SNAP will use extended or expanded memory for Task C, but not a mixture of both simultaneously. SNAP III requires expanded memory for Task C, but XMS memory for all other tasks.

Memory managers such as 386/MAX and Quarterdeck's QEMM provide you with disk caching, the ability to tuck resident programs into high memory, and to partition your computer's extended memory between expanded memory and extended memory. Partitioning is useful because some programs use only expanded memory and not extended memory. Your computer comes "stock" with only extended memory and not expanded memory.

Any partitioning of memory takes place at the time the computer is initializing and cannot be changed without redoing your CONFIG.SYS file and rebooting.

When a memory manager divides the memory between expanded memory and extended memory, SNAP will use the expanded memory for Task C and ignores the extended memory. If the memory manager is disabled, then SNAP will use extended memory for Task C. If, when you set up the memory manager, you did not allocate sufficient memory to expanded memory, SNAP cannot carry out Task C (the ANALYSIS).

What was left of the extended memory after any allocation to expanded memory is available for Tasks A, B, and D. This is ok if there is both sufficient expanded memory to do Task C and sufficient extended memory left over for Tasks A, B, and D.

How much is sufficient? It depends on the size of the problem, but for a 500 polygon problem you probably want at least 2700 k expanded memory and at least 500 k extended memory left. To check your memory allocation, look at your CONFIG.SYS file and see what your memory manager is set for.

If you are using 386/MAX then it will say something like EMS=#####. You want ##### to be 2700 or larger in some multiple of 16. The rest will be extended memory.

If you are using QEMM then you specify how much extended memory (EXTMEM) you want and EMS is the rest.

What happens if you can't have both EMS>2700 and more than 500 k of extended memory?

There are a couple of ways to operate:

1) The simplest way is to deactivate (or comment out) the memory manager. This leaves all of your extended memory unpartitioned. SNAP will use as much of the extended memory as it needs for tasks A, B, C, and D when and if it needs to.

What do you lose? You lose the features of your memory manager which means no tucking programs in high memory and no disk cache. Losing access to high memory is only a problem if you have less than about 520 k of your 640 base. Losing your disk cache is not much of a problem if SNAP has enough extended memory because SNAP builds its own "disk cache" so to speak by storing point and stick data in extended memory where it can reach it quickly.

2) Allocate EMS>2700 and live with less than 500 k extended memory. This will allow SNAP to complete Task C, BUT

Task A may not be completed. SNAP may halt with a message like, "Not enough extended memory - Give me more". This is a warning. You can press enter to continue and SNAP will build your files, but SNAP will not have had enough memory to complete the data necessary to do Graphic Report 6 on Habitat Effectiveness.

Task B may not be satisfactory. You may not get enough rows in the editors to handle your Sale and Link data. These editors count on having sufficient extended memory to give large editor capability.

Task D may go more slowly. The Report Writer is set up to use extended memory. If you do not have enough, SNAP will read from the hard disk. Your disk cache will probably compensate for not having the extended memory in the Report Writer.

DOS 5.0 & 6.0 USERS (SNAP II only)

If you are loading DOS into high memory using the DOS=HIGH command in your CONFIG.SYS file, you will need to include the DOS interrupt (/int15) in the HIMEM specification to access extended memory for SNAP as follows:

DEVICE=C:\DOS\HIMEM.SYS /int15=XXXX

where XXXX is the amount of extended memory you want. One megabyte of extended memory (XXXX=1000) should be adequate.

DOS 6.0 USERS (SNAP III only)

SNAP III requires at least 570,000 free bytes of conventional memory to function properly. With the configuration mentioned above, this should not be a problem. If necessary, the size of the disk cache (smartdrv.exe) can be decreased. An example configuration to run SNAP III is

Gateway 100MHz Pentium

32 megabytes RAM

1 gigbyte HD with MSDOS 6.22

PS/2 style mouse

c:\dos\smartdrv.exe 8192 8192

c:\msmouse\mouse

device=c:\dos\himem.sys /testmem:off

device=c:\dos\emm386.exe RAM I=B000-B7FF

files=60

dos=umb

dos=high

stacks=9,256

SNAP will not run under WINDOWS. You will need to have an alternate CONFIG.SYS file for SNAP.