GoldSim provides a number of units to represent time (e.g., day, sec, hr). Like all units in GoldSim, time units must have a constant definition. For example, the definition of a day is 86400 seconds.
In this regard, there are two time units in GoldSim that warrant special attention: “mon” (month) and “yr” (year). (Note that “a” can also be used for year).
In particular, these units should be used sparingly (if at all), and if they are used, it should be done with great caution. To understand why, consider a case where you were specifying a rainfall rate in an input field. You could, for example, define a rainfall rate as 3 mm/mon. If you were to do so, during a simulation, you might assume then that this implies that 3 mm will fall in January, 3 mm will fall in February, and so on. If this was the case, this would actually mean that the rainfall rate was changing (since January has more days than February, it would imply that the rate of rainfall in February was higher). That is, it would mean that 3 mm/mon is not a constant value in time over the simulation!
However, like all other units in GoldSim, “mon” and “yr” must have a fixed definition. And as a result, 3 mm/mon is a constant value that does not in fact change with time (i.e., based on the simulated month). This is because the unit “mon” is defined as follows: 1 mon is equal to 30.4375 days. It is the average length of a month (365.25 days/12). So 3 mm/mon would be interpreted by GoldSim as 3 mm/30.4375 days = 0.09856 mm/day. Similarly, the unit “yr” (or “a”) is defined as follows: 1 yr or 1 a is equal to 365.25 days.
The problem, of course, is that the actual length of a month and a year change with time, and hence referencing the units “mon” and “yr” in your model can be ambiguous. GoldSim enforces a constant definition for these units (the length of an average month and the length of an average year) so there is in fact no ambiguity, but this could easily be misunderstood by someone viewing your model. As a result, as a general rule, unless it is very clear that you are referring to average months or years (i.e., the actual calendar date is not critical for the simulation), you should avoid using the units “mon” and “yr” in your models.