Time issue with demand_eq

[gwenchee]

Currently, the eval function evaluates the demand_eq state variable in no_inst.py with the notion that time is in seconds. However, it is unclear to the user what time step length the t variable should be.

This issue can be closed when:

1. A state variable that defines what the demand eq’s time step length is: second/day/month/year. The default will be set as month.
2. The README is updated to tell the user that this new state variable must be the same as the dt variable defined in the control section of the cyclus input file.

[jbae11]

wouldn't it be easier if we just did t = self.context.time instead of messing with the whole dt variable?
Without it the user can have an intuitive sense of time rather than having to convert the time into other units.
so if the dt in the simulation is a month (2592000 secs), the equation t variable would be in months.

    def demand_calc(self, time):
        """
        Calculate the electrical demand at a given timestep (time).

        Parameters
        ----------
        time : int
            The timestep that the demand will be calculated at.
        Returns
        -------
        demand : The calculated demand at a given timestep.
        """
        t = time
        demand = eval(self.demand_eq)
        return demand

[jbae11]

But generally I agree the clarification in the readme is needed

[FlanFlanagan]

We can do that, but you need to ensure that the user puts their equation in with regard to the timestep.

Also, not all growth rates will be in regard to the operational time step of the simulation. For example you might consider your growth rate annually, but the time step of the simulation might be weeks, or months, or even seconds. In which case the demand equation needs to account for these differences.

I suppose this is acceptable, since we're already asking users to understand how to input a equation via eval, so they much have some knowledge of how to write python. I'm just hesitant to put most of the burden on the user, when we could solve the problem on the developer side.

[gwenchee]

So from my understanding, we can move forward in two ways:

1. Assume that dt is a month and tell the user that the input in the demand_eq assumes that time is in month-long time steps.
2. Generalize it so that the user can define the time step length of their demand_eq.

Option 1 is easier to implement but we lose generality. I personally would be in favor of option 2. Perhaps, we could implement only month-long and year-long time step options (and not provide minute/second options).

Thoughts? @jbae11 @FlanFlanagan

[jbae11]

I think the best way is option 2 with default month. If @FlanFlanagan agrees, I'll make a PR about it once #40 gets merged.

[gwenchee]

Let's do Option 3:
Make it clear to the user that the demand_eq should have the same time step length as the dt that they defined in the simulation control. Default dt is month-long and so, default demand_eq will also be a month.

[FlanFlanagan]

Option 3 is my vote.

[jbae11]

okay, I'll make the PR once #47 is merged.

[gwenchee]

closed with #46