Refactor: combine simulator implementations

[sgreenbury]

Following on from #345 and #373, currently there will be two base class implementations for a simulator that have different initial purposes (active learning and application to cardiac modelling).

As part of the refactor, we should aim to harmonise the two implementations and ensure a subsequent refactored base class:

• has all required functionality for current applications
• has any envisaged required implementations for future applications

[marjanfamili]

should the base simulator have a run batch method ?

    
    def run_batch_simulations(self, samples: Union[List[Dict[str, float]], pd.DataFrame]) -> np.ndarray:
        """
        Run multiple simulations with different parameters.
        
        Args:
            samples: List of parameter dictionaries or DataFrame of parameters
            
        Returns:
            2D array of simulation results
        """
        if isinstance(samples, pd.DataFrame):
            samples = samples.to_dict(orient="records")
        
        results = []
        successful = 0
        
        # Import tqdm here to avoid potential import errors
        try:
            from tqdm.auto import tqdm as progress_bar
        except ImportError:
            # Fallback to a simple progress tracking if tqdm is not available
            def progress_bar(iterable, **kwargs):
                return iterable
                
        # Process each sample with progress tracking
        for sample in progress_bar(samples, desc="Running simulations", unit="sample"):
            result = self.sample_forward(sample)
            if result is not None:
                results.append(result)
                successful += 1
        
        # Report results
        print(f"Successfully completed {successful}/{len(samples)} simulations ({successful/len(samples)*100:.1f}%)")
        
        # Convert results to numpy array
        if results:
            return np.array(results)
        else:
            return np.array([])

[sgreenbury]

Noting from discussion with @cisprague, @edwardchalstrey1:

• Similar functionality, method names mainly required change
• A good test for this is checking the simulator class works for the tutorials currently making use of a base simulator (04_active_learning, 07_AE_workflow)

[radka-j]

@EdwinB12 flagging #438 as potentially relevant to this

[EdwinB12]

Chat with @sgreenbury:

• What is the responsibility of the Simulator class? Is it to capture all the metadata and parameters of the simulation aswell as giving functionality to run it in AutoEmulate. E.g. Input and output shapes

[EdwinB12]

Discussion with team:

• Need a schema for how the input data into a Simulator should look
• Need a schema for how output data from the Simulator should look

[radka-j]

I think if the idea is for users to wrap their own Python simulators in our Simulator class, we should make this as easy as possible for them. This means that the Simulator class should hold everything. We should have a very good reason for implementing additional classes that capture data schema/metadata etc. as it introduces additional complexity for the user - what are the benefits of doing this?