The target was not to redesign the whole pump, minimize the time-to-market of the new version, but to review its core feature, the design of its gears and lateral plates that interface with them (light and dark red highlighted components in Figure 1b). These parts are geometrically constrained by its connection to a pre-existing housing. The main purpose of the optimization was to reduce the overall noise emission of the pump: from huge internal oscillating forces inside the pump able to excite the structure (structure-borne noise) and from pressure fluctuations propagating through the hydraulic circuit (fluid-borne noise) pressure waves arise (air-borne noise) and cause annoyance in their surrounding environment. The other main purpose of optimization is the maximization of both volumetric and hydro-mechanical efficiencies (this means to reduce leakages and friction between internal components) in order to minimize power absorbed from the prime mover and consequently energy consumption of the overall system.

Figure 3 | Phase 1 - results

Figure 4 | Pump timing through lateral plates grooves

The first step of optimization was the gear design: an internally developed software was used to calculate not only standard features like gear contact ratio and tooth strength, but also more specific parameters important for a hydraulic pump, like specific displacement (quantity of oil the gear can draw for each mm of length), tooth tip, minimum tooth space volume and kinematic flow pulsation (directly related to pressure ripple and noise). This software was included inside a modeFRONTIER workflow (Figure 2) and a really fast MOGAII optimization simulated 100’000 designs in a short time: 1630 designs were feasible (better performances compared to current pump, Figure 3). The best solutions suggested an increase in the number of teeth compared to the current gear. As a further verification, the new design has been validated with KISSsoft commercial software.
Once the gear design is fixed, it is crucial to deeply analyze the meshing process (Figure 4) from a hydraulic point of view: small oil compressibility combined with trapping phase of each vane leads to huge pressure peaks and cavitation insurgence, both of them being sources of pressure ripple and noise emission. The standard solution is to machine some grooves on lateral plates in order to accurately fix the pump timing: they define when and how to connect each pumping vane to external ports. After having parametrized lateral grooves’ geometry, a precise model is necessary to properly simulate the pump’s behavior. Casappa R&D Department can count on HYGESim (HYdraulic GEar machines SIMulator, Figure 5): it is a completely customized virtual platform able to simulate gear pumps, starting from 3D CAD files. Its functioning is based on a pump lumped parameter model developed in Siemens- LMS AMESim that can simulate fluid-dynamics and basic mechanics inside the pump; also, it is coupled to other independent modules able to perform acoustic, tribological and FSI calculations. This platform has been developed through years of cooperation with University of Parma and University of Purdue.
HYGESim is composed of a hydraulic part, where each vane and all the fluid connections are described, as well as a mechanical part. It is able to predict pressure and cavitation distribution, flow/pressure ripple in the circuit, contact forces between components and as a result the volumetric and hydro-mechanical efficiencies of the pump. The optimization of pump timing was performed with modeFRONTIER workflow depicted in Figure 6. Starting from the CAD generation of lateral plate’s grooves, a C++ code combines all components’ geometries together and gives input to HYGESim circuital model, that simulates the pump in different working conditions; the resulting data is post-processed by an Octave script. 7 constraints on input variables are necessary to ensure a good interface between components; 10 constraints on output variables guarantee that the new pump will perform better than previous one in every aspect and every working condition (feasibility condition). It is a hard job for the optimizer to respect so many constraints, but at the end it properly reflects the target of this activity. 4 objective functions manage the physical quantities mostly related to noise and efficiencies.
The standard procedure (Figure 7), usually followed to solve this problem, is to define a range for each input variable, generate a good and feasible DOE population and then run the optimization with MOGAII algorithm. In case the Pareto frontier is acceptable, a further single objective optimization can be done to refine the best solution; if the frontier is not good enough, it is used to reconsider the input ranges and MOGAII settings to loop the process once more. In this specific case MOGAII results were not properly satisfying and an alternative procedure has been followed: MOGT algorithm, based on John Nash theory, was chosen because of its potentials for super-constrained problems, while adapting each setting to its requests. What follows is the report of the comparison between results obtained with both the procedures described above.