tf.keras.models.save_model function. If you are using PyTorch, you can use the torch.save function. You could also just save the weights of the model.tf.keras.models.load_model function. If you are using PyTorch, you can use the torch.load function.Make sure the federated learning version is working correctly.
If not alread done, you will need to containerize your server and client code. Then, put the client part in a folder called learning and the server part in a folder called aggregation. Both folders should contain one Dockerfile to build the respective images.
When using the PHT, the communication between server and client is done by our implementation. Your code interacts with our system through the filesystem, which it can use to write results/models to and read results from previous learning rounds from. We provide environment variables for the respective locations that can be used to interact with the system, as described in the following.
In the client/learning side, the place where the local models are written to is provided via an environment variable called FEDERATED_MODEL_PATH. This is also where your algorithm can read the global model from (starting from the second learning round since usually none will be provided in the first one). You can use the location provided by FEDERATED_MODEL_PATH however you like. This means you can write multiple files, create subfolders etc. Any structure that is created by your analysis will then be transfered to our central service and provided to your aggregation algorithm as is. From this perspective, the one thing that you have to ensure when splitting your analysis into learning and aggregation parts is that the structure used in the filesystem is compatible between the two.
In server/aggregation side, the place where the local models from clients is stored is provided via an environment variable called FEDERATED_AGGREGATION_PATH. In this folder, each client will have their own subfolder where their local model is stored. The idea here is that the aggregation can read the results provided by each client one by one. Morevoer, as mentioned in bulletpoint 3, the sub-folder per client will have exactly the same structure as provided by our analysis algorithm.
You can find all subfolders either by scanning the filesystem, our by using the environment variable FEDERATED_AGGREGATION_PATHS that is also provided by us. This variable contains a comma seperated list of all subfolders (see above for examples). Therefore, you can read in the value, split the strings by “,” and then read in the client results one-by-one.
Once you are done with your aggregation, the aggregation output should be stored in the location provided by the FEDERATED_MODEL_PATH environment variable. Here, the same principle applies: Any structure in this folder will be provided as is to the client and can then be read in for the next learning round. Therefore, your aggregation can also provide multiple files/models, subfolders etc.
Whenver we execute a learning or aggregation round, our ecosystem will create a new container from the images you provided to the cosystem. This means, that any changes you write to the filesystem will be gone after the round has finished. Of course, any changes you write to the FEDERATED_MODEL_PATH location will be distributed to the server/clients but these results will not be available to your analysis in the next round. Therefore, we provide two ways of caching any intermediate results or other values that you might need for your analysis. Both, your aggregation and learning code can use the following locations for caching:
FEDERATED_LOCAL_STORAGE: A subfolder that can be used as a cache. Any changes written to this location will be available for all learning/aggregation rounds. For example, if you create a file with intermediate results in the first learning round, you can read it from the same location with the same name and content in any subsequent rounds. If you change the file afteward, those changes will also be available but not the contents of the file before the change.FEDERATED_GLOBAL_STORAGE: This subfolder works in the same way as the FEDERATED_LOCAL_STORAGE, however the contents of the folder will also be transmitted to our central service and provided as a final, downloadable result after the whole analysis is finished. For example, this caching folder can be used to store metadata associated with your analysis like model performance scores (accuracy, recall, etc.). In this example, the learning/aggregation would create a metadata file in the first learning round and then append the results of subsequent rounds to that file. After the anaylsis is finished, the whole file (containing all results) will be provided to the scientist.