Loading record on initialized model set `Option<Module>` to None
patata3000 opened this issue · comments
Describe the bug
Records don't seem to be saved or loaded correctly with Option<Module>
.
To Reproduce
When saving model after training, the model is saved with a field that is an Option<Module>
that is set to Some(...)
.
The training config is saved as well.
Then init
is called on the loaded TrainingConfig
.
Then is the time to load the record on the initialized model with load_record
. Weirdly, the Option<Module>
field is set to None
.
Expected behavior
When loading record, the field should be set to the saved Some(...)
.
Desktop (please complete the following information):
- OS: nixos
- Browser : not applicable
- Version: Burn 0.13.2
Additional context
Sorry, for now, don't bother. I may have f***ed up configuration. I'm closing. If I get sure of the error, I'll reopen it. I may have tried to save some (sub)configs that were not deriving Config
.
Reopening as it was not a configuration problem. Using the DefaultRecorder
or CompactRecorder
for models gives back None
for Option<SomeEnum>
. I've not tried with anything else than Enum
Probably related to #1893.
When you get the chance, can you try your use case with the latest branch? We just merged #1902 and I think this will solve your issue.
I'm gonna try in the next few days. Was not available last week
Ok so I tried to make it work. Now I have a new problem. I'm trying to derive Module
AND Config
for the same enum and I get
conflicting implementations of trait `std::fmt::Display` for type `evaluator::dynamic_model::TensorDimension`
conflicting implementation for `evaluator::dynamic_model::TensorDimension` [E0119]
Moreover, I cannot derive Module
for enums that are struct like.
#[derive(Debug, Module, Clone)]
pub enum TensorDimension {
Chw {
channel: usize, // no field `channel` on type `&evaluator::dynamic_model::TensorDimension` unknown field [E0609]
height: usize, // Same error for all fields.
width: usize,
},
Hw {
height: usize,
width: usize,
}, // Batch-Height-Width
Flat {
length: usize,
},
}
What about Display
duplicate? Should I make 2 differents enum?
What about enums with struct fields? Should I change this to tuples? I prefered struct though.
Named enum modules are not supported yet (ref #1343). Shouldn't be too difficult to extend the support based on the current derive macro for tuple enum but we haven't seen a lot of use cases for that yet.
Regarding Config
and Module
conflicts, usually both are separate. Think this conflicts comes from a recent PR to add display capabilities to inspect a module. But I'm not sure in your example why the TensorDimension
enum needs to be a module?
If I understand correctly though the original issue has been resolved with the PR linked in the previous comment?
Not checked yet, it's a small refacto to use 2 different enums for modules and config
I confirm, I get Some
instead of None
But I'm not sure in your example why the TensorDimension enum needs to be a module?
I need to have a Module because I need to reshape tensors and I don't have a fixed model. Model is static between trainings but is defined programmatically. So I need the info of the shape of the tensor to know if I need to make a reshape.