Tariff Region #661

dean-krueger · 2025-08-06T19:45:03Z

Summary of Changes

I feel like I've seen this suggestion for a region pop up often enough, especially in my conversations with @gonuke that I figured it'd be fun to just go ahead and make one.

This is TariffRegion. It allows users to specify "friend" regions and "enemy" regions within the simulation and then impose tariffs on the enemies, and subsidies on the friends. The subsidies and tariffs are applied to all trades coming from those regions, so this is fairly basic (it'd be nice maybe later to make it so that only specific commodities from those regions got affected, but I threw this together last night and this afternoon, so I didn't get that far).

Related CEPs and Issues

This PR is related to:

Closes [Feature] Cycamore Could Use More Regions #660
Closes [Feature] Add blanket tarrif/subsidy capability #667
Allow Cyclus to Record the Adjusted Preference/Cost of Trades cyclus#1897 (this is what I was messing with when I found this issue)
Add GetRegion and GetInstitution Functions to R-I-F Hierarchy cyclus#1914

Associated Developers

Cursor AI

Design Notes

Believe it or not, I did most of this on my own. Cursor helped a bit here and there, obviously, but mostly with me understanding how things worked (and the occasional quick "hit tab to fill in the rest of this in that similar function" bits). The basics of this were based on the tutorial PR version of TariffRegion, so I guess in that sense Cursor did a bit more of the heavy lifting.

Testing and Validation

All tests pass. Cyclus and Cycamore both build, and both sets of tests pass with these changes. Unit tests have NOT been added for this Agent.

Checklist

Read the Contributing to Cyclus guide.
Compile and run locally.
Follow style guidelines.
Update the changelog.
Address all review comments.
Reviewers, please refer to the Cyclus Guide for Reviewers.

github-actions · 2025-08-06T19:53:00Z

Build Status Report - `72db1b8` - 2025-12-04 11:26:53 -0600

Build `FROM cyclus_20.04_apt/cyclus:latest`

Cycamore: Success ✅
Cymetric: Failure ❌

Build `FROM cyclus_20.04_apt/cyclus:stable`

Cycamore: Failure ❌
Cymetric: Skipped due to upstream failure ⚠️

Build `FROM cyclus_20.04_conda/cyclus:latest`

Cycamore: Success ✅
Cymetric: Failure ❌

Build `FROM cyclus_20.04_conda/cyclus:stable`

Cycamore: Failure ❌
Cymetric: Skipped due to upstream failure ⚠️

Build `FROM cyclus_22.04_apt/cyclus:latest`

Cycamore: Success ✅
Cymetric: Failure ❌

Build `FROM cyclus_22.04_apt/cyclus:stable`

Cycamore: Failure ❌
Cymetric: Skipped due to upstream failure ⚠️

Build `FROM cyclus_22.04_conda/cyclus:latest`

Cycamore: Success ✅
Cymetric: Failure ❌

Build `FROM cyclus_22.04_conda/cyclus:stable`

Cycamore: Failure ❌
Cymetric: Skipped due to upstream failure ⚠️

Build `FROM cyclus_24.04_apt/cyclus:latest`

Cycamore: Success ✅
Cymetric: Failure ❌

Build `FROM cyclus_24.04_apt/cyclus:stable`

Cycamore: Failure ❌
Cymetric: Skipped due to upstream failure ⚠️

Build `FROM cyclus_24.04_conda/cyclus:latest`

Cycamore: Success ✅
Cymetric: Failure ❌

Build `FROM cyclus_24.04_conda/cyclus:stable`

Cycamore: Failure ❌
Cymetric: Skipped due to upstream failure ⚠️

dean-krueger · 2025-08-06T20:01:33Z

Here are some pictures of what the TariffRegion does (in conjunction with cyclus/cyclus#1897 and a hack I made for testing where sources bid in at a cost of 10.0)

Notice that for subsidies greater than 100% (1.0) the cost goes to 0, and not something negative or nan-like. Ignore the country names and which ones get tariffs and subsidies, I sort of just picked countries as they came to mind and then semi-randomly made them friends/enemies.

gonuke · 2025-08-07T00:15:07Z

Saying a lot about who your friends/enemies are 🤣

But seriously....

What if we didn't need to specify as friends vs enemies, and just had one list of regions and one set of multipliers that are either positive or negative depending on whether it's a tariff or subsidy?

gonuke · 2025-08-07T00:15:50Z

You said all test pass, but there are no new tests and these don't impact existing tests.

dean-krueger · 2025-08-07T14:40:23Z

Oh, oops. I didn't realize I said that twice. I meant that this doesn't break any other cyclus or cycamore tests, which I guess it shouldn't because it's its own thing, so you make a good point. As for your point about just a list of regions to adjust with a corresponding list of adjustments, that's not a bad idea. I'm a little too fond of organizing things into little boxes, so in my head it feels nicer to have them in the "appropriate place", but I guess they don't need to be, and that would probably simplify things.

…ngle tariff which can be positive or negative for a tariff or subsidy

dean-krueger · 2025-08-10T14:59:30Z

Okay, the whole friend/enemy thing has been removed and now you just add "adjustments" which are tariffs/subsidies through positive or negative values in the adjustment list. Tried to make the documentation clear that it was going to be 1 + whatever the value was (ie a 25% tariff would be 0.25 and adjust the value by x1.25, and a 12.5% subsidy would be -0.125). Here's a screen grab of the new region block, and some output showing it working (note that "France" and "Germany" are still in the simulation, but since they don't appear in the region list of Tariff Region they don't get adjusted).

I'm holding off on adding tests until cyclus/cyclus#1897 gets merged, since without that there isn't a really good way to test this region (unless you can think of one).

gonuke · 2025-08-10T16:56:31Z

Can't you test by checking the values of adjusted trades in memory, I.e. before/independent from writing to the DB?

gonuke

Interesting to think through the best nesting of various loops in the adjustment process

gonuke · 2025-08-10T16:58:05Z

src/tariff_region.h

+
+  #pragma cyclus var { \
+    "default": [], \
+    "doc": "Adjustments (1+val) to apply to trades from affected " \


Suggested change

"doc": "Adjustments (1+val) to apply to trades from affected " \

"doc": "Adjustments (multiply by (1+val)) to apply to cost of trades from affected " \

src/tariff_region.cc

gonuke · 2025-08-10T17:06:10Z

src/tariff_region.cc

+      // Traverse up the hierarchy to get the supplier's region
+      cyclus::Region* supplier_region = nullptr;
+      cyclus::Agent* current = supplier;
+      while (current != nullptr) {
+        supplier_region = dynamic_cast<cyclus::Region*>(current);
+        if (supplier_region != nullptr) {
+          break;  // Found a region
+        }
+        current = current->parent();
+      }


This seems like a useful functionality to have somewhere in Cyclus. In most cases, this should just be parent()->parent(), but your approach allows for more complex hierarchies in the future, e.g. subfacilities, etc.

See Agent::AncestorOf(), AgentDescendentOf(), and Agent::InFamilyTree()...

I THINK Agent::AncestorOf(), etc would be really nice if we could somehow just jump to the Region, but because (at least I don't think) you can't access the list of all agents (it's a private member that RIF's don't have access to), it's hard to do something like is "this Agent" an ancestor of "that Agent". At least in a Region. I agree, though, that those functions you mentioned below (FindRegionByName) would be a nice function in Cyclus, where I think it would be possible to do something like that.

Let's try implementing some kind of GetRegion() (and GetInstitution()) for each Facility

gonuke · 2025-08-10T17:31:51Z

src/tariff_region.h

+  cyclus::Region* FindRegionByName(const std::string& name);
+  cyclus::Region* FindRegionInHierarchy(cyclus::Agent* agent, const std::string& name);


I don't see these implemented anywhere... surprised that it builds....

These are probably better implemented in cyclus/cyclus anyway

Yeah, they were leftovers from an old implementation route I was going down before I decided to switch gears. I got rid of them (though I do think a FindAgentByName(std::string name) function in Cyclus/Cyclus would be pretty nice...)

dean-krueger · 2025-08-19T14:08:30Z

Can't you test by checking the values of adjusted trades in memory, I.e. before/independent from writing to the DB?

Probably, yeah. I was holding back on doing this partially because it was less clear how to do, and partially because it's not (so far as I know) how we "typically" write these tests (or at least not how I've typically approached them). If you'd like me to try going down that road, though, I'd be happy to do so!

dean-krueger · 2025-08-19T15:22:27Z

okay, I gave this a close read and I think I caught all the stuff we usually talk about in these reviews. Trying to be better/more careful with what I submit so it's a little easier to review now that I have some "commonly identified suggestions" to think about. Can't promise I've gotten them all, but I think it should be pretty close!

gonuke

A few more comments here on some cyclus infrastructure help

gonuke · 2025-08-20T16:04:17Z

src/tariff_region.h

+          double cost_multiplier = 1.0 + adjustments[it - region_names.begin()];
+          double pref = 1.0 / cost_multiplier;


Does this honor the existing preference before adjustment?

I believe so, but I should have called it "pref_multiplier", since three lines later we do bid_pair.second *= pref_multiplier, where bid_pair.second is the preference of the bid. I'll fix this.

gonuke · 2025-08-20T16:13:29Z

src/tariff_region.cc

+      cyclus::Region* supplier_region = nullptr;
+      cyclus::Agent* current = supplier;
+      while (current != nullptr) {
+        supplier_region = dynamic_cast<cyclus::Region*>(current);


Check Agent->kind() for "Region"

I did some poking into this, and my new understanding is that if we were to do something like if (current->kind() == "Region") { we'd need to then dynamic_cast to region anyway to return the pointer to the region anyway (which is what we want in the end), so checking that way would be redundant. I'm working on converting this to a facility function and then using that in tariff_region now, so maybe it'll make sense in that context?

gonuke · 2025-08-20T16:26:36Z

src/tariff_region.cc

+      // Traverse up the hierarchy to get the supplier's region
+      cyclus::Region* supplier_region = nullptr;
+      cyclus::Agent* current = supplier;
+      while (current != nullptr) {
+        supplier_region = dynamic_cast<cyclus::Region*>(current);
+        if (supplier_region != nullptr) {
+          break;  // Found a region
+        }
+        current = current->parent();
+      }


Let's try implementing some kind of GetRegion() (and GetInstitution()) for each Facility

…what it does

dean-krueger · 2025-11-12T22:33:53Z

I feel very strong negative emotions about the data types available on our back end. I keep trying to do something clever and then I just can't? I'm going to address the comments in this PR review without it for now, but mark my words I will be coming back to the back-end.

dean-krueger · 2025-11-12T22:37:11Z

Might need to consider all the possible permutations now that the complexity of this has increased.

In general, we have a list of rules:

supplier_region

commodity

adjustment

For the flat adjustments as implemented now, I have recommended we just implement that as a rule with commodity == "".

I will address this now

There are two permutations not yet implemented:

an adjustment for some_commodity to be applied to all regions - perhaps with supplier_region == ""?

a flat adjustment to be applied to all commodities from all regions, perhaps with supplier_region == commodity == ""?>

Both of these would require additional inputs

I am going to hold off on this because the input file structure for this is making me feel physically ill to look at, and at this point I am very certain I want to wrestle with (later) the back end, so it'd be a bummer to implement this now and then just redo it later.

dean-krueger · 2025-11-12T23:24:08Z

okay, I went through these comments and fixed the ones where it felt like it was worth doing it now (in case I don't mess with the back end and restructure this), but I left some of them as is because it is my understanding that they're "technically" working and if I did a restructure they'd just be completely irrelevant. We can/should talk about this during the FCS meeting tomorrow, and I am intentionally not re-requesting review because of that.

… few tweaks to some loop structure

gonuke

A few more tweaks while you think about backends

gonuke · 2025-11-13T03:13:30Z

src/tariff_region.cc

+}
+
+void TariffRegion::Tock() {
+    RecordTariffConfiguration();


Do we need to do this every Tock()? It doesn't change over time, does it?

Good point! I wonder if I can move that to EnterNotify(), and if not I'll just add an if (!ConfigurationRecorded()) {} catch to avoid doing it every time.

Is there a reason it couldn't be done in EnterNotify?

And if not EnterNotify then slightly better in the Tick before the DRE uses it

gonuke · 2025-11-14T17:03:57Z

src/tariff_region.h

+  // Template function to reduce code duplication between AdjustMatlPrefs and 
+  // AdjustProductPrefs
+  template<typename T>
+  void AdjustPrefsImpl(typename cyclus::PrefMap<T>::type& prefs) {
+    for (auto& req_pair : prefs) {
+      std::string commodity = req_pair.first->commodity();
+
+      for (auto& bid_pair : req_pair.second) {
+        cyclus::Bid<T>* bid = bid_pair.first;
+        cyclus::Facility* supplier = dynamic_cast<cyclus::Facility*>(bid->bidder()->manager());
+
+        // Find if any of the supplier's parent regions match our tariff list
+        cyclus::Region* matching_region = FindMatchingRegion(supplier);
+        if (matching_region) {
+          double adjustment = FindTariffForCommodity(matching_region, commodity);
+
+          double cost_multiplier = 1.0 + adjustment;
+          double pref_multiplier = 1.0 / cost_multiplier;
+          double inf = std::numeric_limits<double>::infinity(); 
+
+          bid_pair.second *= cost_multiplier > 0.0 ? pref_multiplier : inf; 
+        }
+      }
+    }
+  }


These often live outside the the class declaration, at the end of this file, appropriately scoped, i.e. void TariffRegion::AdjustPrefsImpl(...

I didn't know that, but glad I do now! I'll look into doing it this way.

src/tariff_region.cc

…l no tests.

…inition, fixed a typo in the logger

dean-krueger · 2025-11-17T22:56:02Z

⚠️ NOTE: THIS PR STILL LACKS TESTS ⚠️

Should be ready for another round of review! In conjunction with cyclus/cyclus#1922 we now have a new datatype on the backend of cyclus (somehow that was the easy part of all this), and now TariffRegion has been completely refactored to use that instead of all those horrid lists. This should hopefully make it FAR easier to parse the code (and input files) and understand what's going on.

I've also included an example XML input file in the input folder (which I figured was probably for that sort of thing) which both shows off the new input structure, and also provides users with an example of how to use a TariffRegion. I would love if @nsryan2 and Taesuk (whose GitHub ID I don't know but who I'll ping on slack) would take a look at that and maybe take it for a spin if they have time (but also I know you guys are busy so no worries if you can't).

Finally, I've attached a few pictures of the tables this Region generates in the output:

Blanket Tariffs (Tariffs on all goods from each named region):

Commodity Specific Tariffs (Tariffs on specific commodities from specific regions, the "normal" kind):

Global Blanket Tariff (A tariff on all goods coming from all regions into the TariffRegion):

Global Commodity Tariff (Tariffs on certain commodities regardless of where they come from):

(Just to get ahead of it, combining these tables would probably be a massive pain, but idk maybe not)

It's worth noting that TariffRegion uses an "overriding" tariff system. That is: tariffs with higher priority override tariffs with lower priority, they do not add. The priority list is recorded in the code as a comment, but I'll list it here as well:

Tiered override system (most specific to least specific):

Region-specific commodity adjustment (highest priority)
Region blanket adjustment
Global commodity adjustment
Global blanket adjustment (lowest priority)

I highly recommend that reviewers glance at the input file structure first and then if they approve of that mark it as viewed or something since that accounts for ~350/600 lines of code added in this PR.

Hopefully this Region is what everyone was looking for in spirit! It's been a lot of fun to develop, and I think will be equally fun/interesting to use with some of the other stuff I've got coming down the pipe.

…r each field, added an example of tariff_region being used to the input directory

… tariff-region

dean-krueger · 2025-11-24T04:01:06Z

Needs a slight refactor after the modifications made to cyclus/cyclus#1922. Cannot use empty maps any longer. Must populate commodities with "dummy" empty ones (or real ones with a 0% adjustment) when not imposing commodity-based tariffs.

dean-krueger · 2025-11-24T04:13:19Z

Just occurred to me that being able to specify a time at which tariffs become active (with a default like -1 signifying "from the beginning of the simulation) would be REALLY nice for each commodity. Not sure if that involves adding another back-end datatype, but if it does what a wonderful opportunity that would be to test the tutorial...

dean-krueger · 2025-11-24T05:21:46Z

It will be important to, at some point (this is a bit of a chicken and egg issue I'm realizing), to adjust the implementation of the actual "tariff" part of this facility to match the "Welfare Economics" model we're hoping to use in Cyclus. Right now it assumes the weight-function is always 1/pref, and then updates the PREFERENCES during the preference adjustment phase of the DRE, but we may want to start thinking of that phase more as a a arc weight adjustment phase and using agents like this to modify either MC or MU or some other method of modifying the arc weight directly (typically modifying MC or MU should modify the "cost")

gonuke · 2025-11-24T12:42:53Z

Just occurred to me that being able to specify a time at which tariffs become active (with a default like -1 signifying "from the beginning of the simulation) would be REALLY nice for each commodity. Not sure if that involves adding another back-end datatype, but if it does what a wonderful opportunity that would be to test the tutorial...

I've resisted the urge to bring up time-varying tariffs... I think the input becomes horrific for that...

gonuke

It's getting close... a couple of lingering issues

src/tariff_region.cc

gonuke · 2025-11-24T12:50:53Z

src/tariff_region.cc

+  return region->prototype();
+}
+
+cyclus::Region* TariffRegion::FindMatchingRegion(cyclus::Facility* supplier) {


It looks like this will only ever return the first parent region that matches. Multiple parent regions is currently a rare edge case, but this function is written for the existence of multiple parent regions.

What behavior do we want?

Oh interesting, I did't think of that. I will consult my Tax Law friend and see what he says, but it seems like we have the following problem/options:

Imagine I am Madison, and I want to order a good from my hometown of Webster Groves, which is in St Louis, which is in Missouri. The following tariff structure exists between Madison and all those regions:

Webster Groves: 1% on all goods
St. Louis: 10% on all goods
Missouri: 5% on all goods

Would I want to aggregate the tariffs and impose a 16% tariff on a good coming from Webster groves, take the highest tariff from the nested structure (ie 10%), take the “most superior” tariff (ie the 5% from Missouri), or the most “literal” tariff: the 1% from Missouri? Furthermore, if those are the rules for Madison, but Wisconsin has its own tariff relationship with those regions, since Madison is a sub-region of Wisconsin, how does that relationship work?

I will get back with what his thoughts are, and we can discuss. Fun question!

I will consult my Tax Law friend and see what he says

After a lengthy parenthetical about why "Tariff" is a bad word to use for these due to the unconstitutionality of interstate tariffs, he basically said "It depends a lot on the actual wording of the source of the 'tariff', at which point you could basically get any behavior you wanted, so it might be best to just pick a behavior, state it clearly so everyone knows what it's modeling, and then if someone else wants different behavior tell them they can change/add it if they want".

I'm going to do some more poking around to see if I can't find a good justification for one type of behavior over another, but probably just picking something, making it clear what we're doing, and sticking with it will be the best route forward.

Okay, after some thought here's what I think makes the most sense:

Aggregate adjustments from importers along hierarchy of trade below the "Lowest Common Ancestor" of both regions you're trading between for the most specific rule they have to apply. For example, imagine a hierarchy that looks like this:

Mars
---Federation of Independent Martian Colonies
------Zixzorp
Earth
---USA
------Wisconsin
---------Madison
------Missouri
---------Saint Louis
------------Webster Groves
------Illinois
---------Chicago
---Canada
------Ontario
---------Toronto
------Alberta
---------Calgary

Each region and sub region is allowed to be a TariffRegion, and thus have its own rules about each other region in the simulation. Imagine, then a trade between Webster and Madison. What I'm proposing is that we:

take our two regions, compute their Lowest Common Ancestor (LCA), which in this case would be the USA region

compute the chain of travel, which here would be Webster --> Saint Louis --> Missouri --> Wisconsin --> Madison

For all TariffRegions on the importer side (Madison and Wisconsin)
a. Find the most specific tariff to apply
b. Add all those up

So for instance, if Madison had these rules:

Webster Groves 1%
St. Louis 10%
Missouri 5%
United States 0%
Rest of World 12%

and Wisconsin had these rules:

Missouri 7%
United States 1%
Rest of World 8%

We would see Madison has a specific rule about Webster, so it gets 1% from Webster --> Madison
We would see Wisconsin has no Webster specific rule --> check parent: no specific saint Louis rule --> Check parent: a specific rule about Missouri so it gets 7% from Missouri --> Wisconsin

And the total tariff to apply is 1% + 7% = 8%

Since there is probably no single right answer here, I'm happy with any choice that makes sense and is well documented.

gonuke · 2025-11-24T12:52:55Z

src/tariff_region.cc

+    // Tier 2: Use region blanket adjustment
+    double region_blanket = region_data.first;
+    if (region_blanket != 0.0) {
+      return region_blanket;  // Override global adjustments
+    }


Is there a way to exempt a region from the global adjustment?

That doesn't sound very much like a global adjustment...

But I see your point. No is the answer, and I am tempted to say we shouldn't add that, but if you feel strongly about it I can.

Happy to leave this for now. Can you make an issues for this as a feature request?

gonuke · 2025-11-24T12:57:16Z

src/tariff_region.h

+  // clang-format off
+  #pragma cyclus var { \
+    "default": {}, \
+    "alias": ["adjustment_regions", "region", ["RegionConfig", "blanket_adjustment", ["commodity_adjustments", "commodity", "adjustment"]]], \


Recommend calling this "TariffConfig" instead

Suggested change

"alias": ["adjustment_regions", "region", ["RegionConfig", "blanket_adjustment", ["commodity_adjustments", "commodity", "adjustment"]]], \

"alias": ["adjustment_regions", "region", ["TariffConfig", "blanket_adjustment", ["commodity_adjustments", "commodity", "adjustment"]]], \

I can do that! I'll make that change with a few other ones on my end and then push (for some reason the "commit change" on GitHub option scares me)

Should be done now!

…hat you couldn't have empty maps any longer

…ither way

…s in the hierarchy and the behavior should be as described in my comment on the subject

dean-krueger · 2025-12-04T17:28:53Z

⚠️ NOTE: THIS PR STILL LACKS TESTS ⚠️

I think the time-varying tariffs needs to be kicked down the road, but is something that should be added later for sure (I can make an issue if you agree), and the "global-but-not-quite-because-there-are-exceptions" adjustments I think is maybe not the best idea. If you feel strongly about either of these let me know. Otherwise I think this is good for another round of review!

gonuke

A few more thoughts and concerns about how this actually functions. I worry that the scope has crept by considering complicated region ancestries that are, frankly, not that common.

gonuke · 2025-12-11T13:16:28Z

src/tariff_region.cc

+}
+
+void TariffRegion::Tock() {
+    RecordTariffConfiguration();


And if not EnterNotify then slightly better in the Tick before the DRE uses it

gonuke · 2025-12-11T13:17:00Z

src/tariff_region.cc

+    }
+  }
+
+  // No common ancestor found (shouldn't happen in a well-formed simulation)


This seems like it will be quite common. In the simplest case that has more than one region, there would be two regions with no relationship.

gonuke · 2025-12-11T13:21:19Z

src/tariff_region.cc

+    auto region_it = tariff_importer->adjustment_regions_.find(supplier_ancestor_name);
+    if (region_it != tariff_importer->adjustment_regions_.end()) {
+      // Found a match! Now apply the tiered override system for this specific region
+      return tariff_importer->FindTariffForCommodity(supplier_ancestor, commodity);


If there is no rule for this (supplier_region, commodity) pair, what does this return? ~~and do we miss the change to apply a global commodity rule below?~~ I see that the global commodity rule is checked in FindTariffForCommodity)

It does seem like you miss the chance to find a commodity-specific adjustment in an ancestor of this supplier_region... but maybe that's a case you've explicitly decided to avoid.

gonuke · 2025-12-11T13:24:08Z

src/tariff_region.cc

+  auto region_it = adjustment_regions_.find(region_name);
+  if (region_it != adjustment_regions_.end()) {


In the place where we call this, we've just done this search - can we reuse that info somehow?

gonuke · 2025-12-11T13:32:51Z

src/tariff_region.cc

+  // Get supplier's full ancestor chain (for "most specific" lookups)
+  std::vector<cyclus::Region*> supplier_hierarchy = GetAncestorChain(supplier_region);
+
+  // Get importer chain: from requester up to (but not including) LCA


If you added an optional variable to GetAncestorChain could you use it to get this truncated chain?
importer_chain = GetAncestorChain(requester_region, lca);

gonuke · 2025-12-11T13:36:55Z

src/tariff_region.h

+  #pragma cyclus var { \
+    "default": 0.0, \
+    "doc": "Optional global blanket adjustment applied to all regions and commodities." \
+  }
+  double global_blanket_adjustment;
+
+  #pragma cyclus var { \
+    "default": {}, \
+    "alias": ["global_commodity_adjustments", "commodity", "adjustment"], \
+    "doc": "Optional global commodity adjustments applied to all regions for specific commodities." \
+  }
+  std::map<std::string, double> global_commodity_adjustments_;


What if these just lived in your normal adjustment_regions_ list, but we used "*" for global region and "*" for global commodities. Then you wouldn't need to worry about empty lists. You could still extract and store that data in useful data structures after reading the XML (maybe in EnterNotify())?

dean-krueger · 2025-12-11T22:07:25Z

Unless this comment gets updated, it seems like we decided to axe the whole "super region import tariff structure" thing since currently nobody uses that, which I think also resolves most of these other comments (except maybe the location of the record function). I'll work on doing that (probably tomorrow).

dean-krueger added 3 commits August 6, 2025 14:14

first attempt at a tariff region. nominally it works

9a090ce

fixed products to look like materials

1afed45

removed reference to old friend_regions and enemy_regions vectors

f223a9e

dean-krueger requested review from gonuke and munkm August 6, 2025 19:45

dean-krueger self-assigned this Aug 6, 2025

dean-krueger added the Feature label Aug 6, 2025

changelog

dcfba68

dean-krueger added 3 commits August 10, 2025 09:50

removed friend/enemy designation and just lumped everything into a si…

f5d7b56

…ngle tariff which can be positive or negative for a tariff or subsidy

made documentation in tariffs entry more clear

7e84754

changed tariff to adjustment since they can be positive or negative

5c6bf1e

gonuke requested changes Aug 10, 2025

View reviewed changes

dean-krueger added 4 commits August 19, 2025 09:37

reworded doc in pragma for adjustments

9fc9c9d

removed leftover function signatures from an earlier implementation

7583c75

templated Adjust<matl/product>bid functions to reduce code duplication

0b7a179

rewrote if (var != nullptr) to if (var)

e69e482

dean-krueger requested a review from gonuke August 19, 2025 15:22

gonuke requested changes Aug 20, 2025

View reviewed changes

dean-krueger added the DK Side Project label Aug 26, 2025

dean-krueger added 2 commits August 27, 2025 15:21

changed variable pref in header to pref_multiplier to better reflect …

ce88ca1

…what it does

simplified logic using new cyclus functions from #1914

3545250

dean-krueger removed the DK Side Project label Nov 10, 2025

changed some variable names to make them easier to understand, made a…

7d1c71f

… few tweaks to some loop structure

gonuke requested changes Nov 14, 2025

View reviewed changes

refactored entirely to use new datatype from cyclus/cyclus#1922. Stil…

ce232f5

…l no tests.

dean-krueger mentioned this pull request Nov 17, 2025

Add new Datatype to the Backend for Tariff Region cyclus/cyclus#1922

Merged

9 tasks

dean-krueger and others added 2 commits November 17, 2025 16:33

added a check to the config recorder, moved template out of class def…

da1addc

…inition, fixed a typo in the logger

Merge branch 'main' into tariff-region

e34d274

dean-krueger added 3 commits November 17, 2025 19:46

added aliases to the xml schema to let users put in readable names fo…

eeb2873

…r each field, added an example of tariff_region being used to the input directory

Merge branch 'tariff-region' of github.com:dean-krueger/cycamore into…

bdaee88

… tariff-region

added all options to the example file

e6d6fe3

dean-krueger requested a review from gonuke November 18, 2025 02:12

dean-krueger added this to the Demonstrating Fuel Cycle Economic Capabilities in Cyclus milestone Nov 24, 2025

gonuke requested changes Nov 24, 2025

View reviewed changes

dean-krueger added 3 commits December 4, 2025 11:04

updated example file to include dummy commodity since we made it so t…

9cf210d

…hat you couldn't have empty maps any longer

changed to . Went with adjustment instead of tariff since it can go e…

db1d099

…ither way

made it so that we should have good coverage for nested tariff region…

72db1b8

…s in the hierarchy and the behavior should be as described in my comment on the subject

dean-krueger requested a review from gonuke December 4, 2025 17:29

gonuke requested changes Dec 11, 2025

View reviewed changes

gonuke modified the milestones: Demonstrating Fuel Cycle Economic Capabilities in Cyclus, M_02_01: Cost adders (Tariffs, Sanctions, Shipping, Etc) #NEUP #DK_Research Jan 2, 2026

	"doc": "Adjustments (1+val) to apply to trades from affected " \
	"doc": "Adjustments (multiply by (1+val)) to apply to cost of trades from affected " \

		cyclus::Region* FindRegionByName(const std::string& name);
		cyclus::Region* FindRegionInHierarchy(cyclus::Agent* agent, const std::string& name);

		double cost_multiplier = 1.0 + adjustments[it - region_names.begin()];
		double pref = 1.0 / cost_multiplier;

	"alias": ["adjustment_regions", "region", ["RegionConfig", "blanket_adjustment", ["commodity_adjustments", "commodity", "adjustment"]]], \
	"alias": ["adjustment_regions", "region", ["TariffConfig", "blanket_adjustment", ["commodity_adjustments", "commodity", "adjustment"]]], \

		auto region_it = adjustment_regions_.find(region_name);
		if (region_it != adjustment_regions_.end()) {

Tariff Region #661

Are you sure you want to change the base?

Tariff Region #661

Uh oh!

Conversation

dean-krueger commented Aug 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary of Changes

Related CEPs and Issues

Associated Developers

Design Notes

Testing and Validation

Checklist

Uh oh!

github-actions bot commented Aug 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Build Status Report - 72db1b8 - 2025-12-04 11:26:53 -0600

Build FROM cyclus_20.04_apt/cyclus:latest

Build FROM cyclus_20.04_apt/cyclus:stable

Build FROM cyclus_20.04_conda/cyclus:latest

Build FROM cyclus_20.04_conda/cyclus:stable

Build FROM cyclus_22.04_apt/cyclus:latest

Build FROM cyclus_22.04_apt/cyclus:stable

Build FROM cyclus_22.04_conda/cyclus:latest

Build FROM cyclus_22.04_conda/cyclus:stable

Build FROM cyclus_24.04_apt/cyclus:latest

Build FROM cyclus_24.04_apt/cyclus:stable

Build FROM cyclus_24.04_conda/cyclus:latest

Build FROM cyclus_24.04_conda/cyclus:stable

Uh oh!

dean-krueger commented Aug 6, 2025

Uh oh!

gonuke commented Aug 7, 2025

Uh oh!

gonuke commented Aug 7, 2025

Uh oh!

dean-krueger commented Aug 7, 2025

Uh oh!

dean-krueger commented Aug 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gonuke commented Aug 10, 2025

Uh oh!

gonuke left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dean-krueger commented Aug 19, 2025

Uh oh!

dean-krueger commented Aug 19, 2025

Uh oh!

gonuke left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dean-krueger commented Nov 12, 2025

Uh oh!

dean-krueger commented Aug 6, 2025 •

edited

Loading

github-actions bot commented Aug 6, 2025 •

edited

Loading

Build Status Report - `72db1b8` - 2025-12-04 11:26:53 -0600

Build `FROM cyclus_20.04_apt/cyclus:latest`

Build `FROM cyclus_20.04_apt/cyclus:stable`

Build `FROM cyclus_20.04_conda/cyclus:latest`

Build `FROM cyclus_20.04_conda/cyclus:stable`

Build `FROM cyclus_22.04_apt/cyclus:latest`

Build `FROM cyclus_22.04_apt/cyclus:stable`

Build `FROM cyclus_22.04_conda/cyclus:latest`

Build `FROM cyclus_22.04_conda/cyclus:stable`

Build `FROM cyclus_24.04_apt/cyclus:latest`

Build `FROM cyclus_24.04_apt/cyclus:stable`

Build `FROM cyclus_24.04_conda/cyclus:latest`

Build `FROM cyclus_24.04_conda/cyclus:stable`

dean-krueger commented Aug 10, 2025 •

edited

Loading

dean-krueger commented Nov 12, 2025 •

edited

Loading

dean-krueger commented Nov 17, 2025 •

edited

Loading