It may depend on which SLAMM version you are using. However, in general you click edit cells, make your edits using draw/fill cells, and when done you may simply close the window and you will be asked if you want to overwrite the raster (the raster will have same name as the original one but with the edits) or click "Save As ..." and save the raster and project with different names. Hope this solves your problems.
I am not sure I have completely understood the question.
If you have already a land cover layer with dry land cells then the problem may be in the elevation layer.
If your land cover layer has blank cells in the dry land portions, then the problem may be that you have some optimization selected in the File Setup window. First, you have to select "Track all cells" in the File Setup window. After loading the map you should be able to see the elevations in the blank cells and then convert blank to dry land. After saving the new land cover layer with filled dryland you can select again the optimization you desire in the File Setup window.
If you do not solve the problem, probably it would be best to have a look at the elevation and land cover layers.
Let me add some practical details. You cannot edit and save a dbf in excel and then save it. So, we usually: (1) make a copy of the dbf (saved the old one as *_old.dbf just in case of mistakes). (2) open the new dbf in excel and copy the land cover attributes (3) paste them into the lookup excel file (4) as Jonathan wrote, check if all the codes have been crosswalked and if not try to determine the correct crosswalk. (5) Copy the crosswalked column (from row one to the last, not the entire column) (6) Open the dbf using Open Office Calc. (7) Paste the data as a new attribute column (e.g. SLAMMCLASS) and save. (Sometime saving is not possible because the precision of some attribute columns. You can change them accordingly in the first row, e.g. Length,N,10,5 is the attribute Length with 10 digits total and 5 digits after the comma).
SLAMM produces projections from the initial date T0 of the land cover layer to the last year of your simulation. So, if your initial date of the land cover layer is set to 2050 (but then why not set the last year of simulation to T0+1?), then only one year is run.
There are several reasons why results may depend on the time step.
First, SLAMM does only one conversion at each time steps. So for example, it will still take at least 3 time steps to convert dry land to water because first it is converted to transitional marsh, then tidal flat and then water no matter the time step. So this may lead a different results for different time steps depending on how fast elevation is lost. But if elevation losses are so fast then one would question if model assumptions hold (see comment below).
Second, conversion is calculated only at the end of each time step. This also may lead different results because using a smaller time step a land conversion may occur earlier according to the elevation loss and after that land cover type will have a different decision tree and loss elevation rates until next time step.
Having more time steps is better, but you have to balance with the fact that SLAMM assumes land cover in quasi-equilibrium with SLR. Two time steps calculations in 25 years may be reasonable.
You can change the elevation ranges of all land cover classes through the Elevation Analysis window. See User Guide document.
There are other compilers, Free Pascal for example. We have not tested the compatibility with recent codes but last time it was tried, some of the syntax needed to be modified. Therefore some work may be required to successfully build a working executable.
SLAMM can model uplift but unfortunately does not model the land cover changes due to aggradation. The model will not crash but for example a marsh area that keeps gaining elevation with respect to sea level will not become dry land at any point.
As a rule of thumb we usually consider it calibrated if the land cover conversion are less than 5% but if additional information explains observed conversions then the calibration can be considered acceptable. For example, if satellite maps show tidal flats instead of marshes then it may be acceptable to have a higher conversion.
Tidal flat is coming from the conversion of low regularly-flooded marsh. So, this may be an issue of your marsh elevations that are too low with respect to the modeled tides. Or maybe from satellite images these areas are actually tidal flats ....
I am still confused on what is the problem you are having. Are you predicting too much TF in the future? Or at time zero?
If it is at time zero, then the conversion to TF is not controlled by accretion but by the fact that your marsh elevations are initially too low with respect to the modeled tides and thus the areas are converted to TF.
If it is in the future, it all depends on the rate of SLR and time horizon. If SLR is not so high then TF will not convert to water fast enough. TF looses elevation at a rate of (BSR-SLR) mm/yr and normally converted to open water when it falls below -1 HTU (but you can change it if you think it is not corresponding to your study area).
BSR controls sedimentation rate of TF and beaches, while marshes are controlled by separate accretion rates values. So there is no built-in connection between the rate marsh and TF/beaches accrete.
Maybe you meant asking if you could assign different sedimentation rates for TF and beaches. This unfortunately can only be done through modifying the function TSLAMM_Simulation.TidalFlat_Sed in the source code. Hopefully in the future, a NEW SLAMM version will have this option.
As long as the sum of all land cover types are equal to the study area in both cases (otherwise there is a problem ...), I think that this discrepancy is because the numerical calculation reported in the tables accounts also of partial conversion of a cell, e.g. 30% IFM and 70% RFM, while the raster only show the majority of the land cover in a cell, e.g. 100% RFM.
Considering all uncertainties, I would not worry too much about these differences in the sense that your conclusions should be pretty much the same whether you use one number or the other. Obviously an uncertainty analysis would be more robust to achieve confidence on the predictions of land parcels that are at the edge of different land cover types ....
In any case, when possible, I would use the numbers of the output data tables.