WwZzz

> Traceback (most recent call last): File "/home/archlab/lzr/easyFL-FLGo/main.py", line 31, in runner.run() File "/home/archlab/lzr/easyFL-FLGo/flgo/algorithm/fedbase.py", line 243, in run updated = self.iterate() File "/home/archlab/lzr/easyFL-FLGo/flgo/algorithm/fedasync.py", line 25, in iterate res = self.communicate(self.selected_clients,...

HierFL里的 配置文件config_hier_mnist.py的内容如下： ``` import os import torchvision import torch import flgo.benchmark transform = torchvision.transforms.Compose( [torchvision.transforms.ToTensor(), torchvision.transforms.Normalize((0.1307,), (0.3081,))] ) path = os.path.join(flgo.benchmark.path, 'RAW_DATA', 'MNIST') # 定义训练集实例，并命名为train_data train_data = torchvision.datasets.MNIST(root=path, train=True, download=True,...

> class DiversityPartitioner(BasicPartitioner): """`Partition the indices of samples in the original dataset according to numbers of types of a particular attribute (e.g. label) . This way of partition is widely...

> 定义一开始的客户端，然后在需要新的客户端加入时，再进行数据的分配，并将其加入训练过程，如果目前不能实现的话，我是否能 你好，1）目前数据集的分配不能够动态地进行，每个task生成后用户的数据分布就是固定的了，这种设置也比较贴合实际情形；2）另一方面我不明确你所描述的波动的客户端的具体含义；如果是指部分用户对于服务器在训练早期不可见，而后期训练过程中动态加入的话，可以在Simulator中通过设置用户的活跃性实现，比如分别设置每个用户活跃的起点轮数，即从某一轮开始后变成始终活跃；这样服务器通过available_clients属性可以访问每一轮活跃的用户，从而无法在早期接触到没加入的用户；如果指的是服务器主动增添新的客户端的话，我认为可以不对用户做修改，通过设置服务器的行为实现相同的效果，比如一开始只与self.clients中的前10个用户交互，后面逐步扩充交互用户的规模

> > > 定义一开始的客户端，然后在需要新的客户端加入时，再进行数据的分配，并将其加入训练过程，如果目前不能实现的话，我是否能 > > > > > > 你好，1）目前数据集的分配不能够动态地进行，每个task生成后用户的数据分布就是固定的了，这种设置也比较贴合实际情形;2）另一方面我不明确你所描述的波动的客户端的具体含义;如果是指部分用户对于服务器在训练早期不可见，而后期训练过程中动态加入的话，可以在Simulator中通过设置用户的活跃性实现，比如分别设置每个用户活跃的起点轮数，即从某一轮开始后变成始终活跃;这样服务器通过available_clients属性可以访问每一轮活跃的用户，从而无法在早期接触到没加入的用户;如果指的是服务器主动增添新的客户端的话，我认为可以不对用户做修改，通过设置服务器的行为实现相同的效果，比如一开始只与self.clients中的前10个用户交互，后面逐步扩充交互用户的规模 > > 集合波动性就是可用的客户可能在不同的时间发生变化，并且可能有新的客户加入培训。我所设想的理想情况是能够在初始化是先设定一批客户端，在随后的训练过程需要有新的客户端集加入时，独立的进行数据分配并将其加入系统中，如果现在没有办法解决，我会考虑您所说的解决方案，您也可以考虑一下这方面的代码，我认为以后的联邦学习可能也会从波动性入手 你好，可用的用户可能在不同的时间发生变化这个概念在FL里现有工作一般称作Intermittent Client Availability，具体论文包括MIFA、F3AST等。有新的用户加入训练有一篇忘了名字的ICML论文称作Flexiable Participation。如果是实现Client Availability的话，我想这个tutorials可以帮到你https://flgo-xmu.github.io/Tutorials/4_Simulator_Customization/4.1_Client_Availability/ ，此外我觉得从Client Availability角度去模拟Flexiable Participation也是可行的。

> 轮可用设备还随着被选择客户端数量减少 你好，这个变量的含义是：在同一个聚合轮次内，用户的availability是否会随着时间变化。我贴了一个例子来解释这件事：这里simulator1是roundwise_fixed_availability=True, simulator2是False（后面简称该变量为rfa）。然后我稍微修改了下fedavg算法，让服务器在每个iterate里通过self.gv.clock.step(1)让时间强制流逝1个时间单位。此时若rfa为True，则用户的availability在下次模型聚合之前，不会随着时间变化而变化；若rfa为False，则用户的availability会随着时间变化而变化，与聚合轮次无关。 ```python import flgo import flgo.algorithm.fedavg as fedavg import flgo.simulator.base as fsb import random class MySimulator1(fsb.BasicSimulator): def update_client_availability(self): if self.gv.clock.current_time==0: self.set_variable(self.all_clients, 'prob_available', [1 for _ in self.clients])...

> 请问，在cifar10数据集中，我使用DiversityPartitioner将客户端只塞入了一种标签的数据，设置了100个客户端，每轮选择10个客户端，测试精度出现多个0.1000是什么原因 下面是我的设置： `option = {'proportion':0.1,'num_rounds':50, 'gpu':0,'learning_rate':0.01, 'batch_size':40, 'num_epochs':3}` > >  你好，这种情况是因为noniid程度太极端，同时local epoch过大，导致模型收敛极慢甚至无法收敛；此时需要调小local epoch（或直接设置num_steps替代num_epochs）或是调小learning_rate，才能观察到数十个round内损失稳定下降；或是用使用一些针对niid问题进行了优化的算法替代fedavg；

你好，错误来源于result_analysis文件的默认参数res_config.yml所指定的画图plot中，需要指定的y被Logger记录为同名的变量（例，所保存的logger.output字典中需要包含名称为client_datavol的键值对)。由于在后续对logger的更新中取消了对client_datavol进行默认保存，因此报错；现已将client_datavol从res_config.yml中删除并更新至github。谢谢你的反馈

你好，服务器的communicate_with函数接收参数package，这个package由BasicServer.pack函数生成。pack函数接受参数client_id，然后返回一个字典变量。因此，服务器可以在pack函数内部根据client_id为用户生成定制化的包裹（字典）。

数据增强的话在get_batch_data里做可能会比较麻烦？数据增强是对feature的随机变换，在train函数里得到数据后，这时候对feature应用transform代码量可能会比较少；另一方面也可以直接在initialize函数里修改数据集本身，即self.train_data，写一个数据增强类来封装一下