Draft
Conversation
2a054d3 to
4028711
Compare
1221c70 to
d51a1d8
Compare
d51a1d8 to
5e6d988
Compare
This was referenced Jan 7, 2026
8bfa962 to
cac37ff
Compare
4013509 to
6e332e1
Compare
9dda198 to
100d441
Compare
e623079 to
9a493e6
Compare
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
705065f to
ed722e0
Compare
The types should not be partial, in the backend, they are meant to be complete. Only the frontend will have partial types to support entering the configuration, so the frontend will build their own types accordingly.
When a configuration element is itself an object, it can use a `nested` descriptor to provide a descriptor for the sub-fields it supports.
Make the demand in line with the one from batchRoute calculations. Separate the simulation in 3 fields: demand, routing parameters for calculation and additional evaluation options to calculate the cost of a scenario. Add descriptors for each of those methods and update tests accordingly. In the backend, update the simulation method with the new parameters. It does not work anymore. Pseudo-code has been written to describe how the simulation method will have to run.
Type the parameters for a transit network job in general. Add the specific types for the transit network design using the evolutionary algorithm. Add functions to create and replay such a job. Also add an empty executor for the job and a wrapper for it on the workerpool.
* Let the `nested` option type return a descriptor instead of a descriptor factory, to have singleton descriptors * The main `OptionsComponent` will get the default option values at first load instead of callers. The default values will be set whenever the options descriptor changes.
Add some help texts and error to the `TransitNetworkDesignParameters` descriptor. Also add many help texts and errors to the `EvolutionaryAlgorithmDescriptor`.
And translate labels of select data.
The 'askAs' gives an indication of the unit in which the data should be asked from the user, for example, to ask a number of seconds in minutes. The transit routing attributes of the network design are changed to be seconds asked as minutes.
Instead of throwing simple strings, `TrError` objects are thrown in the `getFilePath` method.
When simulating a scenario candidate using the OD trips approach, we sample the original demand file to contain only a certain ratio of the data. For each selected record, a random time is selected as departure time between 8 and 9 am. This time data is added to the demand parameters of the simulation job, as it may not be present in the main file. For now, each file row has a "sample ratio" probability of being included in the final file, which means the file sample may not represent exactly the sample ratio because of the randomness induced.
batch csv demand type has changed for the batch calculation job. We create a similar demande file for the OdTripSimulationMethod type. For sake of simplicity, for now, we keep the whole CsvFileAndMapper type instead of just the field mapping, like in the batch calculation, as it would require a different backend and frontend type with the options descriptor. When we clean the option descriptor classes, we can make sure the case is supported and the options descriptor type apply only to the options configuration and allow for subsequent types in the backend.
Update test files to align with refactored network design and simulation method interfaces: - Update OdTripSimulationFromCsvAttributes mocks to include required `projection` field and all required fieldMappings properties - Update TransitNetworkDesignParameters mocks with new required fields: minTimeBetweenPassages, numberOfLinesMin, numberOfLinesMax, nonSimulatedServices, linesToKeep - Update i18n keys from colon (:) to dot (.) separators to match new format (e.g., transit:networkDesign.parameters.*) - Fix ExecutableJobUtils test to expect TrError instead of plain string - Update OdTripSimulationMethod tests for API changes: descriptor properties, type 'seconds' instead of 'integer', updated mapping descriptor keys - Apply code style fixes: arrow functions, trailing semicolons, spacing
* Rename the `TrRoutingBatch` class to `TrRoutingBatchExecutor` and export it * Make the `handleResults` method public so it can be called from the outside with any visitor. * The `batchRoute` main function of the file remains a wrapper for the job execution and default result processing to generate files, but it is now responsible for handling the default visitor class, such that the executor class itself does not know which result visitor will be used.
…n results Replace the `OdTripSimulation#processResults` method by a `OdTripFitnessVisitor` class, which handles each result independendly and keeps track of final results. Also fixes a bug where any unrouted trip would result in `null` values for many metrics.
And properly type them to identify the discrepancies between the actual fields and what is expected. Fixes the `null` fitness issue, with proper field calls. Also use the non-routable taxi od trip fitness function in case there is no routing found.
fitness functions need to be real ones, not empty strings in the tests.
This type represents a value between 0 and 1, but suggests that UIs or CLI ask for it as a percentage, ie as a value between 0 and 100, to make the user's life easier. Use a formatted input widgets in frontend, so ask to convert to/from a value between 0 and 1 and a percentage.
…n file This lets the db queries import them without creating circular dependencies. Also add the timeBetweenPassages, outbound and inbound path IDs to the `LineLevelOfService` and `ResultSerialization` types as this will be required for saving the results.
This adds 3 tables to store each candidate's results for the genetic algorithm transit network design: * `tr_network_design_gal_results` stores the total fitness for each candidate of each generation * `tr_network_design_gal_simulation_results` saves the details for each simulation methods of candidates, storing its fitness score and data. * `tr_network_design_gal_candidate_lines` store the lines used by each candidate, as well as the number of vehicles used. Add the database queries and test to save/stream the results.
After each generation, save the results of each candidate and simulation to the database. At the end of the job's execution, produce 2 output files: * A candidate line file, which describes for each generation/candidates, the lines that have been used and how many vehicles for each. * A simulation result file, which describes for each generation/candidates, the simulation method used, its fitness and some data.
For simplicity and given the number of schedules generated, the simulations only create schedules for a few hours during a day. But when saving a scenario, in order to simulate it with real data, the schedules need to span the whole day. This adds the collection manager to the network design job, as it is required for the schedules generation. Also, it saves the scenarios, services and modified lines to the main cache after saving, so they are right away available to the user for calculations.
`ErrorMessage` has been moved and renamed to `TranslatableMessage` Also run `yarn format`
All the fields that are not the ones used to create the OD trip (id, coordinates and time) are saved in the trip's `data` field. It is also saved along with the result in the batch results table. This will allow various result visitor to make use of this data, without having to re-read the csv file. For example, to weight the results with a weighting factor column, or calculate the cost according to some additional socio-demographic data available, like age or gender.
Now that all the extra data is available in the result, we can get the expansion factor if the field is set. It defaults to 1 if not set or if it is an incorrect number format.
The `decimal` knex data type converts by default to a `numeric(8,2)` in postgres, effectively making maxing the value to 6 digits with 2 decimals. We use `double` instead to support any floating point value for the fitness score, as it can be quite high for large simulations, for example, with many thousands OD trip pairs, the value can be in the millions or tens of millions. This converts to `double precision` in postgres.
Get more information when the cache collection reading fails and the job ID in completion status update.
The main cache directory may have been reset when the task is resumed, so we need to create the symlink in that case also.
b91e8bf to
181e6a0
Compare
In order to determine for large sample if the current sampling approach (where each line has x% chance of being in the sample, instead of exactly x% of the file) can cause result biases, we add to the simulation results the number of lines effectively in the sample file and the total weight that it represents. From that information, we can decide how urgent it is to change the sampling algorithm (see the FIXME in `OdTripSimulation#sampleOdTripFile` function).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Feature branch for the evolutionary transit network design algorithm implementation.
Current status: It compiles!!!... 👯
TODO:
frontend:
Suivantsoit actif seulement si tout est valide. Tous les champs n'ont pas encore été validésbackend:
resourcesde la tâche. Hypothèse: race condition, manque un await en qq part.