-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SampleSupervisor #101
base: v3.2
Are you sure you want to change the base?
SampleSupervisor #101
Conversation
…here the DEM was downloaded from
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are a lot of changes in this pull request which make it a bit difficult to follow - I have left some comments on the code but I am not sure I follow the design/reasoning completely. I think it is important to think about how this class will interact with the other classes/methods within map2loop. I think a plan either as a design document and/or a flow chart would really help understanding these changes.
When I initially suggested this class my intention was to have a class which has a get_sample()
method for each different type of sample - it then either calls the appropriate sampler or returns the stored data depending on the current state. This would mean that within other samplers there could be a call to the sample_supervisor.get_samples for any other data type (although some care would be needed to prevent circular calls). The motivation behind this method was to allow for the underlying data or sampling algorithm parameters to be changed by the user and then map2loop would only recompute what was/is required. From what I could follow this current implementation does allow for this but the order of the calls is defined by the supervisor instead of the samplers - I think it would make more sense for the samplers to control the ordr because what is actually used by each sampler would be dependent on the algorithm.
I think that the calls to the project should not exists and these functions calculate_fault_orientations, summarise_fault_data, extract_geology_contacts should all be run by sampler type classes that are managed by this class.
My last comment is there seem to some changes to m2l that are included in this pull request that are not really related to the sample supervisor. I know it is a pain to separate but it really makes reviewing the pull request easier if only the relevant changes are in the PR.
from .project import Project | ||
|
||
|
||
class AccessStorage(ABC): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it really necessary to have an abstract class for this? I can't think of a case where there are multiple sample supervisors
def type(self): | ||
return self.storage_label | ||
|
||
def set_default_samplers(self): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't default be chosen with appropriate parameterisation given the map/dataset?
self.sampler_dirtyflags[sampletype] = True | ||
|
||
@beartype.beartype | ||
def get_sampler(self, sampletype: SampleType): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this return the sample not the sample type? and it should be type hinted for the return type
return self.samplers[sampletype].sampler_label | ||
|
||
@beartype.beartype | ||
def store(self, sampletype: SampleType, data): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What type is data? does this matter? Should there be any validation?
datatype = Datatype(sampletype) | ||
|
||
if datatype == Datatype.DTM: | ||
self.map_data.load_raster_map_data(datatype) | ||
|
||
else: | ||
# load map data | ||
self.map_data.load_map_data(datatype) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know this is from the mapdata class, but why can't we just have map_data.load(datatype)? And it takes care of what type the data is? Would probably be more future proof as raster data could also include geophysical grids
sampletype (SampleType): The type of the sample. | ||
""" | ||
|
||
if sampletype == SampleType.CONTACT: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the samplers are changed so that they have a __call__
method this would avoid having to pass different arguments to the sample methods.
self.store( | ||
SampleType.CONTACT, | ||
self.samplers[SampleType.CONTACT].sample( | ||
self.map_data.basal_contacts, self.map_data |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is basal contacts not an attribute of the sample supervisor? Isn't is something that is sampled?
) | ||
|
||
@beartype.beartype | ||
def reprocess(self, sampletype: SampleType): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't really see why there is a reprocess. Shouldn't reprocess just be process?
self.process(SampleType.FOLD) | ||
|
||
@beartype.beartype | ||
def __call__(self, sampletype: SampleType): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like having a call method, I think the logic is a bit complicated. It should just be self.process and return the data. All other checks should be done within process.
… the beginning of the test scripts
edit dddf70b chore: added issue_templates
…here the DEM was downloaded from
Rebasing did not solve the problem of having too many file changes. I will start over in another branch! |
Description
Fixes #(issue)
Type of change
How Has This Been Tested?
All tests performed are included in tests/sample_storage/test_sample_storage.py
Checklist:
Checklist continued (if PR includes changes to documentation)