multicore builds failing to parse CLAs correctly in tests/charm++/load_balancing/lb_test
Since the change to command line argument parsing in charmrun on multicore builds, they are all failing to parse lb_test's arguments properly.
It is skipping over "GreedyLB" as the argument to "+balancer".
testrun +p4 ./lb_test 100 100 10 40 10 1000 ring +balancer GreedyLB +LBDebug 1 Running command: ./lb_test 100 100 10 40 10 1000 ring GreedyLB 1 +p4 +balancer +LBDebug ------------- Processor 0 Exiting: Called CmiAbort ------------ Reason: Abort Charm++ fatal error: Abort Charm++: standalone mode (not using charmrun) Charm++> Running in Multicore mode: 4 threads Converse/Charm++ Commit ID: b132991 CharmLB> Load balancer assumes all CPUs are same. traceprojections was off at initial time. Charm++> Running on 1 unique compute nodes (8-way SMP). Charm++> cpu topology info is gathered in 0.059 seconds. Abort: Unknown load balancer: '+LBDebug'! Available load balancers: * CentralLB: CentralLB base class * DummyLB: Dummy load balancer, like a normal one but with empty strategy * GreedyLB: always assign the heaviest obj onto lightest loaded processor. * GreedyRefineLB: Greedy refinement-based algorithm * CommLB: another variation of CommLB * RandCentLB: Assign objects to processors randomly * RefineLB: Move objects away from overloaded processor to reach average * RefineCommLB: Average load among processors by moving objects away from overloaded processor, communication aware * RotateLB: Rotate each object to the next higher PE * DistributedLB: The distributed load balancer * HierarchicalLB: The scalable hierarchical greedy load balancer * HybridBaseLB: HybridBase load balancer * HybridLB: Hybrid load balancer * ComboCentLB: Allow multiple strategies to work serially * RefineSwapLB: always assign the heaviest obj onto lightest loaded processor. * NeighborLB: The neighborhood load balancer * OrbLB: partition objects based on coordinates * BlockLB: Allocate objects in blocks to the remaining valid PE * GreedyCommLB: Greedy algorithm which takes communication graph into account * NodeLevelLB: Node level load balancer  Stack Traceback: [0:0] CmiAbortHelper+0xbe [0x796e9d] [0:1] CmiGetNonLocal+0 [0x796ed6] [0:2] [0x70baf9] [0:3] _ZN8LBDBInitC1EP8CkArgMsg+0x97 [0x70bb99] [0:4] _ZN16CkIndex_LBDBInit23_call_LBDBInit_CkArgMsgEPvS0_+0x40 [0x70d800] [0:5] _Z10_initCharmiPPc+0x1f3a [0x664f87] [0:6] [0x796c14] [0:7] ConverseInit+0x592 [0x7968d2] [0:8] main+0x3f [0x65bfe7] [0:9] __libc_start_main+0xf0 [0x7ffff6f6f830] [0:10] _start+0x29 [0x605f59]  Stack Traceback: [0:0] [0x797dc1] [0:1] LrtsAbort+0x6f [0x7977fa] [0:2] CmiAbort+0 [0x796ea9] [0:3] CmiGetNonLocal+0 [0x796ed6] [0:4] [0x70baf9] [0:5] _ZN8LBDBInitC1EP8CkArgMsg+0x97 [0x70bb99] [0:6] _ZN16CkIndex_LBDBInit23_call_LBDBInit_CkArgMsgEPvS0_+0x40 [0x70d800] [0:7] _Z10_initCharmiPPc+0x1f3a [0x664f87] [0:8] [0x796c14] [0:9] ConverseInit+0x592 [0x7968d2] [0:10] main+0x3f [0x65bfe7] [0:11] __libc_start_main+0xf0 [0x7ffff6f6f830] [0:12] _start+0x29 [0x605f59]
#2 Updated by Sam White over 1 year ago
- Status changed from New to Implemented