{"id":"fefe2d43-00c2-4992-afab-44f8cb9da206","arxiv_id":"2411.14671","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"high","formal_verification":"none","parameter_count":7,"one_line_summary":"A two-stage train rescheduling method that aggregates rail networks to important nodes and then solves an integer program; restricting optimization to affected trains cuts runtime by up to 88%.","lead":"Train disruptions force rapid rescheduling, and this paper proposes a two-stage optimization approach: pick important nodes by degree and passenger demand, then solve an integer program to re-time trains across the whole network. It is tested on the Iranian railway and a synthetic busy network, where restricting the solver to directly affected trains cuts runtime by up to 88%.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The printed IP formulation is not internally consistent (constraint 2 permits overlapping block occupancy; constraints 12 and 19 use undefined x_{ii}, x_{jj} variables), so the reported schedule and runtime results cannot be attributed to a well-posed model.","rationale":"I read the paper as claiming a practically usable two-stage rescheduling method: aggregate the network to important nodes, solve an IP to get a secondary timetable, and in the adjusted variant solve only for affected trains to cut runtime by up to 88%. The load-bearing condition is that the IP in Table 2 is a correct formalization of train movement and safety. That condition fails on the submitted text: constraint 2 does not exclude overlapping interval occupancy, constraint 5 is not time-resolved, and constraints 12 and 19 reference undefined variables. These are correctness risks, not stylistic issues; they change the feasible set and the meaning of the reported objective values and runtimes. I therefore agree with the reader's REJECT verdict. My objection is different from the reader's stated weakest assumption (aggregation fidelity), though the paper's own Sections 4.1 and 8 admit that omitting nodes can remove overtaking/meet-pass capacity. I would not recommend acceptance or major revision without a corrected formulation, a reproducible implementation, and an aggregation-fidelity check; as submitted, the central claim is unsubstantiated.","tokens_in":15566,"tokens_out":8749,"duration_ms":84251,"concrete_test":"Obtain the authors' CPLEX implementation and run it on the Section 6 test network; compare the implemented constraints with the printed equations 2, 5, 12, and 19. Then, with the printed equations instantiated on a two-train/two-block toy instance, check whether constraint 2 admits a solution where one train occupies two blocks whose time intervals overlap; if the solver rejects undefined x_{ii}/x_{jj} or returns such an overlapping solution, the printed model is not the tested model and the central claim fails.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The decisive soft spot is the printed model itself, not the aggregation approximation. Constraint 2 (∑_{ij∈RU_k} x_{ij}^{k,tt′} ≤ 1) only tests the same indexed interval tt′, yet constraint 6 explicitly reasons about overlapping intervals (tt′∩ll′∩gg′≠∅); as written, a train can be placed on one block in interval [t1,t2] and on another block in an overlapping interval [t3,t4] with t1<t3<t2<t4, violating the assumption that a train occupies at most one block at any time. Constraint 5 is a time-aggregated flow balance whose right-hand side depends on t′=d̅_{O_k}^k while the left-hand sums over all intervals, so it does not enforce temporal continuity of the trajectory. Constraints 12 and 19 use variables x_{jj}^{k,tt′} and x_{ii}^{k,tt′} for self-loop blocks that are never defined and are excluded by i≠j elsewhere, so the capacity constraint cannot be instantiated. Because the paper provides no code or erratum, the reported delays and the 88% runtime reduction cannot be traced to the equations as printed. The aggregation-fidelity risk (Sections 4.1 and 8) is real but secondary; if the formulation is invalid, the empirical claims are unsupported even before aggregation is tested.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes a two-stage methodology for train rescheduling after disruptions. In the first stage, important nodes are identified using a normalized degree/demand importance index, and the network is aggregated around those nodes. In the second stage, an integer programming model is formulated and solved with CPLEX to reschedule trains, with features such as use of opposite tracks, minimum headways, and dwelling/capacity limits. The method is tested on the Iranian railway network and on a synthetic crowded test network; the adjusted model is reported to cut computational time by up to 88%. The central claim is that this pipeline provides a practical network-wide rescheduling tool for disruption management.","tokens_in":15867,"tokens_out":7222,"duration_ms":75528,"significance":"The practical problem is relevant, and the paper honestly lists several limitations in Section 8, including the lack of validation for the aggregation step. If the formulation were correct, the two-stage idea would be a useful contribution to railway disruption management. However, as printed, the integer programming model is not a valid time-respecting train-path formulation: the key constraints permit overlapping block occupations, the flow-balance constraint is time-aggregated, and two constraints use undefined self-loop variables. Because the reported delays and runtimes are presented as solutions of this model, the empirical claims are not supported by the equations. The aggregation-fidelity concern is real but secondary to the formulation errors.","major_comments":[{"comment":"Constraint 2 only restricts the sum of x_{ij}^{k,tt'} over blocks for one and the same indexed interval tt'. Since Constraint 6 explicitly quantifies over overlapping intervals with tt'∩ll'∩gg'≠∅, the model as written allows the same train k to occupy one block in interval [t1,t2] and another block in an overlapping interval [t3,t4] with t1<t3<t2<t4. This violates the stated assumption that a train occupies at most one block at any instant and makes the space-time trajectory ill-defined. The constraint must be written for all pairs of intervals with nonempty intersection, or the interval set must be defined as a partition of the horizon.","section":"Table 2, Constraint 2"},{"comment":"Equation 5 is a time-aggregated flow balance: the left-hand side sums departures and arrivals over all time intervals, while the right-hand side for origins and destinations is specified only at a single time t'=d̄_{O_k}^k. There is no constraint relating the arrival of train k at a node to a later departure from that node, and no temporal ordering of traversed blocks. As written, the auxiliary variables a_i^k and d_i^k, and therefore the objective function, are not tied to a feasible chronological trajectory. A time-expanded network formulation or explicit arrival-before-departure sequencing constraints are needed.","section":"Table 2, Constraint 5"},{"comment":"Equations 12 and 19 use variables x_{jj}^{k,tt'} and x_{ii}^{k,tt'} for self-loop blocks. These variables are never defined, and Constraint 3 explicitly excludes i=j for block variables, so the dwelling-time and capacity constraints cannot be instantiated for any arc in the model. Equation 12 also has an indexing inconsistency: the first term sums over t' without a matching index in the multiplicand, and the second term uses a loop variable t in the multiplier. These constraints must be corrected before the model can be solved or the reported results reproduced.","section":"Table 2, Constraints 12 and 19"},{"comment":"The aggregation step is not validated against the full network. Section 4.1 explicitly states that omitted nodes 'may provide additional capacity for meet-pass and overtaking maneuvers,' and Section 8 repeats that omitting demand from unimportant nodes may negatively affect results, but no experiment compares the rescheduling solution on the aggregated network with the solution on the original network. Without such a comparison, the Iranian case-study delays and the claim that the model can reschedule trains 'across the entire network' are unsupported. This is a load-bearing external-validity gap, albeit secondary to the formulation errors above.","section":"Sections 4.1 and 8"},{"comment":"The reported runtime reduction of up to 88% is obtained by fixing the schedules of trains not in R* and omitting Constraint 20 for affected trains. The feasible regions of the basic and adjusted models are therefore different, so the objective values in Tables 12 and 13 are not directly comparable and the runtime comparison is not an algorithmic speedup on the same problem. The paper should present this as a model-reduction trade-off, with an explicit statement of what is sacrificed (optimality for unaffected trains and the β bound on affected trains), rather than as a pure computational improvement.","section":"Section 7, Tables 12 and 13"}],"minor_comments":[{"comment":"The normalization for nodes with d_i=d_min assigns 0.5/(d_max-d_min) rather than 0; this is an unusual choice that should be justified, since Table 3 shows all degree-1 nodes receiving D_i=0.25.","section":"Section 4.1, Equation 26"},{"comment":"The notation t,t'∈T is overloaded: T denotes both the horizon length and a set of time points, and the interval [t,t'] is never formally defined. The paper should define the set of interval endpoints, the relation t'=t+δ (or the general interval set), and the interpretation of overlapping intervals in Constraints 2 and 6.","section":"Table 1 and Table 2"},{"comment":"The text says the orange hatch indicating the disruption period is in Figure 5, but Figure 5 is captioned as the undisrupted network and Figure 6 is the disrupted one; please clarify which figure contains the hatched disruption interval.","section":"Figures 5 and 6"},{"comment":"The footnote states that one scenario was initially infeasible because of β and was solved after relaxing the corresponding constraint, yet the sensitivity discussion treats all runs in Tables 8 and 9 uniformly; the infeasibility and relaxation should be addressed in the text.","section":"Table 9"},{"comment":"The dummy node at Kashan is introduced manually after the important-node algorithm; please clarify whether this node participates in the importance ranking and how its capacity and dwelling parameters are set.","section":"Section 5.1"},{"comment":"Several typos and wording issues appear, e.g., 'occupying the opposite tacks' in Section 5.3 and 'to encounter the run time issue' in Section 5.4; a careful proofread is needed.","section":"Throughout"}],"recommendation":"reject","confidential_remarks":"The central IP formulation is internally inconsistent at the level of the printed equations: the trajectory-uniqueness, flow-balance, and capacity constraints cannot be instantiated as written, and no code or erratum is provided. The empirical results therefore cannot be attributed to a well-posed model. The aggregation-validation gap is also substantial but would be addressable; the formulation errors would require a rewritten model, so I recommend rejection rather than major revision."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Let me give you the short version. This paper combines two established things—important-node scoring and an integer-programming rescheduling model—and adds opposite-track use and station capacity. That combination, as a single network-wide formulation, is new relative to the cited literature, and the authors say so without overselling. The Iranian case study is a real network, the sensitivity analysis on headway and disruption duration is reasonable, and they openly acknowledge in Section 4.1 that deleting nodes loses overtaking capacity. Those are genuine positives.\n\nThe trouble is the model itself. As printed, Constraint 2 only limits a train to one block per identical time interval, so overlapping intervals let a train occupy two blocks at once. Constraint 5 is a time-aggregated flow balance that never ties arrival at a node to departure from it, so the 'path' need not be time-respecting. Constraints 12 and 19 use self-loop variables x_{ii} and x_{jj} that are never defined and are excluded by i≠j elsewhere. These aren't cosmetic typos; the optimization problem stated in Table 2 is not the problem that would produce the reported schedules. With no code or erratum, there is no way to attribute the delay numbers or the 88% runtime figure to the printed equations.\n\nThe aggregation-fidelity issue—comparing the aggregated solution against the full network—is a real and acknowledged limitation, but it's secondary to the formulation problem. Also, the runtime reduction in the adjusted model is largely a consequence of shrinking the problem to directly affected trains, which is expected.\n\nSo where does that leave us? The core idea has merit, and a careful rewrite could make it a decent contribution. But the current text is not publishable, and a reviewer would need the authors to fix the formulation and supply the actual model code or a precise notation for intervals and self-loops. I would not desk-reject it out of hand—the topic is relevant and the combination is worth a look—but I would send it back for major revision with a clear list of the technical issues. For my own work, I wouldn't cite it in its current form.","headline":"The two-stage aggregation idea is legitimate, but the printed IP model is internally inconsistent, so the reported results stand on sand.","tokens_in":16424,"tokens_out":4155,"would_cite":false,"duration_ms":41322,"reading_group":"no","serious_thinker":"no","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":["90B06","90C10","90B20"],"pacs":[],"model":"deepseek-v4-flash","headline":"This paper claims that a two-stage optimization approach can reschedule an entire disrupted rail network, with an adjusted version cutting computation time by up to 88%.","keywords":["train rescheduling","railway disruption management","integer programming","network aggregation","critical node identification","opposite-track operation","space-time trajectory","transportation digitalization"],"falsifier":"Run the adjusted model on a network that includes every intermediate station, then compute the optimal schedule for the full network under the same disruption; if the aggregated schedule requires an omitted station for a passing or overtaking maneuver, or its total delay is substantially worse than the full-network optimum, the central claim is false. A simpler observable version: on a two-track line with one passing siding at a low-demand station, disrupt the block just before that siding and test whether the compressed network can still produce a feasible plan without the siding.","tokens_in":15301,"feed_emoji":"🚆","tokens_out":5085,"duration_ms":48779,"temperature":0.7,"pith_summary":"The paper tries to establish that a two-stage digitalization method can solve the train rescheduling problem across a whole rail network after a disruption, not just on one block. In the first stage it identifies important stations by combining network topology and passenger demand, then compresses the network around them. In the second stage it solves an integer programming model that minimizes total travel time, allows trains to use opposite tracks during partial block failures, and respects station and block capacity. The authors report that on a sparse real network (the Iranian railway) the model produces small delays, and on a crowded test network an adjusted version that only reschedules directly affected trains cuts computation time by up to 88%. If the claim holds, dispatchers could receive a new network-wide timetable within minutes of a disruption instead of waiting for a slow block-by-block recovery process.","feed_headline":"Whole-network train rescheduling model cuts solve time up to 88%","feed_subtitle":"A two-stage method aggregates the network, then re-times only disrupted trains to produce a fast usable secondary timetable.","key_machinery":"The load-bearing object is the space-time trajectory network with binary arc-occupancy variables $x_{ij}^{k,tt'}$, where each time interval of the horizon is a layer and each block is a possible occupation. On this network the model enforces flow conservation at stations, per-block headways and travel times, dwelling-time and capacity limits, and a conflict constraint $x_{ij}^{k+,tt'}+x_{ij}^{k-,ll'} \\le 1 + b_{ij}-dis_{ij}^{gg'}$, which is the mechanism that permits opposite-track running when a double-track block is partially disrupted. The compression step is carried by the criticality index built from normalized node degree and normalized passenger demand, and the runtime-reduction adjustment is a constraint replacement that fixes the movements of every train outside the directly affected set $R^*$, shrinking the problem to the only trains whose paths intersect the disruption.","core_discovery":"The central discovery is that network-wide train rescheduling after a block disruption can be decomposed into a network-compression step and an optimization step without sacrificing operational realism. The importance index $C_{ri}=(\\bar{D}_i)^{\\alpha_1}(\\bar{P}_i)^{\\alpha_2}\\times 100$ combines normalized node degree with normalized passenger demand, and keeping only the highest-scoring nodes yields a medium-scale network on which an integer program with space-time arc variables finds a new timetable. The model lets a train on a double-track block use the opposite track during a partial disruption, and the adjusted variant freezes all trains not directly affected while optimizing only the affected set, which is what produces the reported runtime reduction. On the Iranian case, a two-hour closure of the critical Tehran–Qom block adds 155 minutes of delay relative to the original timetable, and on the crowded test network the adjusted model solves the disruption scenario in 224 seconds.","pith_inferences":["A direct consequence the paper leaves untested is that the aggregation step's fidelity determines whether the reported runtime gains are real; if omitted low-demand stations are needed for passing and overtaking, the compressed-network schedule could be infeasible or substantially suboptimal in the actual network.","The same two-stage compression idea could be applied to crew and rolling-stock rescheduling during disruptions, since those problems also shrink when the modeled node set is reduced.","A testable extension is to make the affected-train set adaptive: instead of permanently freezing all unaffected trains, let trains re-enter the optimization when delays propagate to them, which would trade some runtime for robustness on longer disruptions."],"forward_implications":["If the claim is correct, operators can produce a network-wide secondary timetable in minutes rather than hours after a disruption, because the adjusted model solved the crowded test scenarios in 153 to 224 seconds.","Partial block failures need not stop traffic on a double-track line, since the model reroutes trains onto the opposite track; in the sparse Iranian case a partial closure of the Tehran–Qom link left the original timetable unchanged.","The importance-index compression makes whole-network rescheduling tractable when the original network has many low-demand stations, because only high-demand, high-degree nodes need to be modeled explicitly.","On sparse networks with low trip frequencies, the results suggest that headway assumptions and disruption duration have only modest effects, while the worst delays occur on the busiest block, indicating where operators should focus capacity investment."],"supporting_citations":[{"why":"Supplies the space-time trajectory representation and credibility-based rescheduling formulation that this model adapts to whole-network operations.","marker":"[11]"},{"why":"Proposes critical-node identification by mean-excess probability, the topological-demand idea behind the paper's importance index.","marker":"[5]"},{"why":"Demonstrates combining topology with passenger data from automated fare collection to find critical metro nodes.","marker":"[7]"},{"why":"Provides an optimization-based resilience model that combines infrastructure restoration and transport management, which this work extends to rescheduling.","marker":"[8]"},{"why":"Classifies real-world railway disruption management practice and motivates the need for fast secondary timetables.","marker":"[20]"},{"why":"Surveys macroscopic rescheduling models operating on timed event graphs, the class of methods this paper extends to entire networks with opposite-track operation.","marker":"[21]"}],"fun_headline_variants":["Train rescheduling model cuts disruption solve time 88%","Network-wide rail rescheduling: 88% faster secondary timetables","Optimized train rescheduling for disrupted networks, 88% faster","Rail disruption solver trims rescheduling time to 224 seconds","Two-stage model reschedules trains across whole network faster"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The whole method rests on the assumption that removing non-important stations, and the passing and overtaking capacity they provide, does not materially change the best rescheduling plan; the paper acknowledges but never tests this.","fun_headline_variants_meta":{"raw":{"variants":["Train rescheduling model cuts disruption solve time 88%","Network-wide rail rescheduling: 88% faster secondary timetables","Optimized train rescheduling for disrupted networks, 88% faster","Rail disruption solver trims rescheduling time to 224 seconds","Two-stage model reschedules trains across whole network faster"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000418,"raw_usage":{"total_tokens":2166,"prompt_tokens":971,"completion_tokens":1195,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":587,"completion_tokens_details":{"reasoning_tokens":1109}},"tokens_in":587,"tokens_out":1195,"duration_ms":8669,"temperature":1.0,"reasoning_tokens":1109,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T15:02:30.768333+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the adjusted model on a network that includes every intermediate station, then compute the optimal schedule for the full network under the same disruption; if the aggregated schedule requires an omitted station for a passing or overtaking maneuver, or its total delay is substantially worse than the full-network optimum, the central claim is false. A simpler observable version: on a two-track line with one passing siding at a low-demand station, disrupt the block just before that siding and test whether the compressed network can still produce a feasible plan without the siding.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the space-time trajectory representation and credibility-based rescheduling formulation that this model adapts to whole-network operations."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Proposes critical-node identification by mean-excess probability, the topological-demand idea behind the paper's importance index."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Demonstrates combining topology with passenger data from automated fare collection to find critical metro nodes."},{"cited_title":"Beˇsinovi´c, R","cited_arxiv_id":null,"evidence_quote":"Provides an optimization-based resilience model that combines infrastructure restoration and transport management, which this work extends to rescheduling."},{"cited_title":"Ghaemi, O","cited_arxiv_id":null,"evidence_quote":"Classifies real-world railway disruption management practice and motivates the need for fast secondary timetables."},{"cited_title":"Kecman, F","cited_arxiv_id":null,"evidence_quote":"Surveys macroscopic rescheduling models operating on timed event graphs, the class of methods this paper extends to entire networks with opposite-track operation."}],"review_version":1}