In order to swap loggers and operators, some minor changes in beast core are needed

[nicfel]

For only swapping loggers instead of states, I swap PrintStreams in the logger class and Accepted/Rejected values in the operator classes. To do so, I currently need to adapt the core Logger and Operator class at the moment: Logger has to have:

    public void setPrintStream(PrintStream m_out_alt){
        m_out = new PrintStream(m_out_alt);     
    }

    public PrintStream getPrintStream(){
        PrintStream m_out_alt = new PrintStream(m_out);
        return m_out_alt;
    }

and Operator has to have:

    // Added for coupled MCMC
    public int get_m_nNrAccepted(){
        return m_nNrAccepted;
    }
    public int get_m_nNrRejected(){
        return m_nNrRejected;
    }
    public int get_m_nNrAcceptedForCorrection(){
        return m_nNrAcceptedForCorrection;
    }
    public int get_m_nNrRejectedForCorrection(){
        return m_nNrRejectedForCorrection;
    }

    // Added for coupled MCMC
    public void setAcceptedRejected(int m_nNrAccepted, int m_nNrRejected, int m_nNrAcceptedForCorrection, int m_nNrRejectedForCorrection){
        this.m_nNrAccepted = m_nNrAccepted;
        this.m_nNrRejected = m_nNrRejected;
        this.m_nNrAcceptedForCorrection = m_nNrAcceptedForCorrection;
        this.m_nNrRejectedForCorrection = m_nNrRejectedForCorrection;
    }

Extending the Logger class should be easy, but extending the Operator class requires also to adapt Operator Scheduling etc.

[rbouckaert]

Swapping the state should make the logger log the newly swapped state, so I am curious, why do you need to swap loggers?

[nicfel]

I don't actually swap states anymore, but only swap the operator, loggers and heating parameters between the chains. This avoid some recalculation and also avoids some issues with packages where swapping states is not that trivial

[rbouckaert]

I can see some recalculation can be prevented (did you time the advantage?), but the second reason sounds not quite right: any state inside a CalculationNode should be reconstructable by refreshing the State, and a call of State.robustlyCalcPosterior(). The only exception I can think of is when the CalculationNode is stochastic, but even then, robustlyCalcPosterior() should put it in a valid state. Did I miss something?

[nicfel]

There is quite large time advantages for IM models, since robust calculation are a lot more expensive than an average recalculation from after normal operation. I guess the same applies to StarBeast analysis.

The only exception I can think of is when the CalculationNode is stochastic, but even then, robustlyCalcPosterior() should put it in a valid state. Did I miss something?

I ran into issues with bacter when swapping states.