Fixes needed to run fixed GM2010 replication

[MichaelTiemann]

These are changes needed to make Gourio and Miao 2010 run to completion (once it is also patched as needed).

[robertdkirkby]

I understand the changes to
‎EvaluateFnOnAgentDist/EvalFnOnAgentDist_AggVars_Case1_withV.m

But I don't get why the changes to
‎HeterogeneousAgent/InfHorz/HeteroAgentStationaryEqm_Case1_subfn.m
are necessary? Is it about getting the inputs to the FnsToEvaluate correct when V is being used? If yes, this should be done earlier in HeteroAgentStationaryEqm_Case1 when they are set up, not by modifying HeteroAgentStationaryEqm_Case1_subfn.

[MichaelTiemann]

I'll give it a go and see if I can lift the change out of the subfn.

[MichaelTiemann]

The bit of GM2010 that activates this code path start at line 357, where it calls HeteroAgentStationaryEqm_Case1 with a value function named V and a 701x10 gpuArray tagging along.

In that function we find this comment at line 266:

%% Change to FnsToEvaluate as cell so that it is not being recomputed all the time

and in particular, this is what we're trying to avoid recalculating:

    AggVarNames=fieldnames(FnsToEvaluate);
    for ff=1:length(AggVarNames)
        temp=getAnonymousFnInputNames(FnsToEvaluate.(AggVarNames{ff}));
        if length(temp)>(l_d+l_aprime+l_a+l_z+l_e)
            FnsToEvaluateParamNames(ff).Names={temp{l_d+l_aprime+l_a+l_z+l_e+1:end}}; % the first inputs will always be (d,aprime,a)
        else
            FnsToEvaluateParamNames(ff).Names={};
        end
        FnsToEvaluateCell{ff}=FnsToEvaluate.(AggVarNames{ff});
    end
    % Now have FnsToEvaluate as structure, FnsToEvaluateCell as cell

We do still use only FnsToEvaluate in this call just before we get into the GE calculations:

    if simoptions.agententryandexit>=1
        [p_eqm,p_eqm_index, GeneralEqmConditions]=HeteroAgentStationaryEqm_Case1_EntryExit(n_d, n_a, n_z, n_p, d_grid, a_grid, z_gridvals, pi_z, ReturnFn, FnsToEvaluate, GeneralEqmEqns, Parameters, DiscountFactorParamNames, ReturnFnParamNames, FnsToEvaluateParamNames, GeneralEqmEqnParamNames, GEPriceParamNames, EntryExitParamNames, heteroagentoptions, simoptions, vfoptions);
        % The EntryExit codes already set p_eqm as a structure.
        varargout={p_eqm,p_eqm_index,GeneralEqmConditions};
        return
    end

Nine months ago, this change (be677bf) added the FnsToEvaluateCell parameter to the subfn's function signature and changed it to call EvalFnOnAgentDist_Case1 with the cell array instead of the structure.

Now, because EvalFnOnAgentDist_AggVars_Case1 has to deal with either the cell array or the structure, and because the subfn still may have to call heteroagentoptions.CustomModelStats (which relies on the structure, not the cell array), the real error was adding the cell array as a separate parameter to the subfn. Instead, we can just send it the cell array or the structure depending on simoptions.eval_valuefn. Or we could conditionalize the creation of the cell array in the first place, and never send it anywhere we know we should be sending the structure. I think that's cleanest.

Shall I make those changes? Or do you want to leave the function signature of the subfn open to receiving two values? In which case...