Ignite: Backwards compability for torch.save in ModelCheckpoint

[kilsenp]

🚀 Feature

Pytorch made some changes to torch.save (https://pytorch.org/docs/stable/generated/torch.save.html)

The 1.6 release of PyTorch switched torch.save to use a new zipfile-based file format. torch.load still retains the ability to load files in the old format. If for any reason you want torch.save to use the old format, pass the kwarg _use_new_zipfile_serialization=False.

It would be useful to have control over this flag when instantiating ModelCheckpoint.

Possible ways that I can think of:

• Have some args, *kwargs passed on to the save function
• Be able to pass the save function itself to ModelCheckpoints
  

[vfdev-5]

@kilsenp thanks for the suggestion !

Maybe, passing args/kwargs would make sense. We also have Checkpoint class where user can specify how to save checkpoints. For example, for local storage we can use DiskSaver which calls torch.save. Forwarding args/kwargs to DiskSaver can be possible...

[kilsenp]

Ah okay, I see.
So when going the route of passing kwargs, I would envision it like this:

class DiskSaver:
def __init__(..., **additional_kwargs):
    self.additional_kwargs = additional_kwargs

def _save_func(...):
    ...
    func(..., **self.additional_kwargs)

and for ModelCheckpoint, the constructor is changed as well.

I can create a pull request for this if this is a good way to go forward.

[vfdev-5]

I can create a pull request for this if this is a good way to go forward.

@kilsenp yes, I think it can be a good way to to do that and, yes, please, send a PR. The only thing we have to check and deal somehow is xm.save from pytorch/xla. Either we do not pass kwargs there or we have to open an Issue/PR at pytorch/xla and propagate things there too... We can start with the 1st option and add 2nd once pytorch/xla are agreed on that.